Not to nitpick, but as something that might be of interest to some readers who aren't aware of this aspect, and hopefully not annoying to those who consider the following unhelpfully pedantic...

There are those who would (and have) upvoted a StackOverflow answer to the question "Compiled vs. Interpreted Languages": which begins:

“compiled programming language” and “interpreted programming language” aren’t meaningful concepts. Any programming language, and I really mean any, can be interpreted or compiled. Thus, interpretation and compilation are implementation techniques, not attributes of languages.

I think it's at least interesting and perhaps significant that the answer I link to and quote above was written in 2015, and has no downvotes, (but only 20 upvotes), whereas the accepted answer was written and accepted in 2010, has 3 downvotes, (but 450 upvotes), and includes a key "no it isn't ... yes it is ... not it isn't" exchange in the comments below it:

This is actually a false dichotomy. There is nothing intrinsic to a language that makes it compiled our interpreted. It is nothing more than a widely held misconception. Many languages have both implementations and all languages can have either.

it is not a false dichotomy. "programming language" includes both design and implementation. While in an theoretical sense a given language definition can be both compiled and interpreted, in real world practice there are considerable differences in implementation. Nobody has yet solved how to effectively compile certain language constructs, for example - it is an open research problem.

it is. There are benefits to compiling and there are benefits to interpreting. Just because compiler technology is developing to improve on certain languages features don't mean we can say anything about the benefits of compiling a language with that feature. Conflating language and implementation causes us to have false understandings of choosing compilation or interpretation for an implementation. For example your comment "[interpreters] Can be more convenient for dynamic languages"

Similarly, from Wikipedia's High-level programming language page:

Note that languages are not strictly interpreted languages or compiled languages. Rather, implementations of language behavior use interpreting or compiling.

This was presumably written by someone who discusses this in the page's Talk page, along with another, saying:

Interpreters and compilers are programs that process programming languages. Languages are not "interpreted" languages or "compiled" languages. Rather, language implementations use interpretation or compilation. For example, Algol 60 and Fortran have both been interpreted (even though they were more typically compiled). Similarly, Scheme has been compiled (even though it has been interpreted in most popular implementations. Java shows the difficulty of trying to apply these labels to languages rather than to implementations; Java is compiled to bytecode and the bytecode is subsequently executed by either interpretation (in a JVM) or compilation (typically with a just-in-time compiler such as HotSpot, again in a JVM).

[Someone else added] Similarly, C# and Visual Basic.Net are compiled to MSIL then just-in-time compiled to native machine code at the time of execution (this is a different strategy than Java as it incurs longer loading times to get the benefit of faster execution).

If I suggest this isn't pedantry then I'll presumably be labeled pedantic. If I suggest it is pedantry then I'll presumably be popular. So I'll do neither and just wrap by noting that all dichotomies are false in reality, but they're easier to understand and so are often better than reality, except when they're worse, which is when you think you know more than Socrates.

Native programs runs using instructions written for the processor they run on.

Interpreted languages are just that, "interpreted". Some other form of instruction is read, and interpreted, by a runtime, which in turn executes native machine instructions.

Think of it this way. If you can talk in your native language to someone, that would generally work faster than having an interpreter having to translate your language into some other language for the listener to understand.

Note that what I am describing above is for when a language is running in an interpreter. There are interpreters for many languages that there is also native linkers for that build native machine instructions. The speed reduction (however the size of that might be) only applies to the interpreted context.

So, it is slightly incorrect to say that the language is slow, rather it is the context in which it is running that is slow.

C# is not an interpreted language, even though it employs an intermediate language (IL), this is JITted to native instructions before being executed, so it has some of the same speed reduction, but not all of it, but I'd bet that if you built a fully fledged interpreter for C# or C++, it would run slower as well.

And just to be clear, when I say "slow", that is of course a relative term.

I refute the premise. There are interpreters / REPLs for compiled, static languages, they're just not as much part of the common workflow as with dynamic languages. Though that also depends on the application. For example, scientists at CERN work a lot in C++ in the Root framework, and they also use the Cling interpreter a lot, an approach which combines many of the advantages of a fast compiled language and a slow interpreted one like Python, especially for scientific purposes.

With some other languages it's even more drastic. Haskell is a static, compiled language (in some ways even more static than OO languages), but it is very common to develop Haskell interactively using GHCi, either as a REPL (see the online version) or just as a quick typechecking pass to highlight what needs to be worked on. Once something is ready implemented, it'll then be part of a library that is always compiled, resulting in fast code, and that can then be called in either a fully-compiled program or in another interactive session.

Of course it can also go the other way around: typical interpreted languages like Python, JavaScript and Common Lisp are all possible to compile at least in some senses of the word (either JIT or a subset of the language can be statically compiled). Though in my opinion this approach is way more limited than starting with a strong statically typed programming language and then using it more interactively, it can still be a good option for optimising the bottleneck parts of an interpreted program, and is indeed commonly done.

You are trying to compare "Code Compiling" vs "Code Interpreting"

"Code Compiling" doesn't execute the code it only creates a binary or platform independent code which can be run over and over again with no need of re-compilation or minimal compilation which has much less overhead than interpreting like in Java

"Code Interpreting" - compiles the code line by line in memory and executes it on the fly

So compiled languages are faster in execution as at the time of execution no compilation is required but in interpreted languages each execution step is preceded by a compilation step every time, making it slow.

No.

In general, the performance of a language implementation is primarily dependent on the amount of money, resources, manpower, research, engineering, and development spent on it.

And specifically, the performance of a particular program is primarily dependent on the amount of thought put into its algorithms.

There are some very fast interpreters out there, and some compilers that generate very slow code.

For example, one of the reasons Forth is still popular, is because in a lot of cases, an interpreted Forth program is faster than the equivalent compiled C program, while at the same time, the user program written in Forth plus the Forth interpreter written in C is smaller than the user program written in C.

This gets somewhat tricky with more modern hybrid languages/runtimes, but I'll go the original route because it's easier to explain.

The simple answer is that in an interpreted language everything you do has to run through an extra layer that translates that into what the physical machine is doing every single time it's run. For example, let's do a + b. In a compiled language that would be one instruction on the CPU something like: iadd a b c. Addition takes about one CPU cycle, so you can do roughly 2 billion of these per second. All the type checking, variable locations and such has already been done.

In an interpreted language the parser will deconstruct a + b into looking up a and b in the current scope, making sure they're the right type, looking up the addition function that suits those types adding and storing back. In a naive implementation this could be 100+ instructions, three+ function calls and multiple memory lookups.

Modern interpreted languages are much better than this, because they're commonly semi-compiled. Java and Python convert their raw code to something called "bytecode" that runs on a virtual machine. The virtual machine is sort of an idealized replica of a computer that you can compile your code to. The benefit is that your code is still fully portable, but you don't have to do all the same looking up/verification that a purely interpreted system does. Take a look at how similar Java's bytecode looks to assembly.

Some virtual machines (like Oracle's JVM, LLVM, PyPy, and Chrome's JavaScript interpreter) do something called "just in time" compilation. If the VM notices a piece of bytecode that's running a lot, it compiles it into hardware instructions so it can run full speed. Because of this, these languages can get very close to the same speed as compiled languages.

However, there's one more thing that keeps many of these from achieving full speed. That's garbage collection. Many modern OO languages let you create a new object, but don't require that you explicitly delete it. This makes our lives much better as programmers, but how does the VM know when to delete it? One of the easiest ways to find unused things is by stopping the VM, looking at all the objects, erasing the inaccessible ones, then resuming it. This is very bad for performance and there's a lot of research in this area for making it better.

If I didn't explain something well enough or you want more detail, I'd be happy to expound.

Cheers!

In programming language design and implementation, there is a large number of choices that can affect performance. I'll only mention a few.

Every language ultimately has to be run by executing machine code. A "compiled" language such as C++ is parsed, decoded, and translated to machine code only once, at compile-time. An "interpreted" language, if implemented in a direct way, is decoded at runtime, at every step, every time. That is, every time we run a statement, the intepreter has to check whether that is an if-then-else, or an assignment, etc. and act accordingly. This means that if we loop 100 times, we decode the same code 100 times, wasting time. Fortunately, interpreters often optimize this through e.g. a just-in-time compiling system. (More correctly, there's no such a thing as a "compiled" or "interpreted" language -- it is a property of the implementation, not of the language. Still, each language often has one widespread implementation, only.)

Different compilers/interpreters perform different optimizations.

If the language has automatic memory management, its implementation has to perform garbage collection. This has a runtime cost, but relieves the programmer from an error-prone task.

A language might be closer to the machine, allowing the expert programmer to micro-optimize everything and squeeze more performance out of the CPU. However, it is arguable if this is actually beneficial in practice, since most programmers do not really micro-optimize, and often a good higher level language can be optimized by the compiler better than what the average programmer would do. (However, sometimes being farther from the machine might have its benefits too! For instance, Haskell is extremely high level, but thanks to its design choices is able to feature very lightweight green threads.)

Static type checking can also help in optimization. In a dynamically typed, interpreted language, every time one computes x - y, the interpreter often has to check whether both x,y are numbers and (e.g.) raise an exception otherwise. This check can be skipped if types were already checked at compile time.

Some languages always report runtime errors in a sane way. If you write a[100] in Java where a has only 20 elements, you get a runtime exception. This requires a runtime check, but provides a much nicer semantics to the programmer than in C, where that would cause undefined behavior, meaning that the program might crash, overwrite some random data in memory, or even perform absolutely anything else (the ISO C standard poses no limits whatsoever).

However, keep in mind that, when evaluating a language, performance is not everything. Don't be obsessed about it. It is a common trap to try to micro-optimize everything, and yet fail to spot that an inefficient algorithm/data structure is being used. Knuth once said "premature optimization is the root of all evil".

Don't underestimate how hard it is to write a program right. Often, it can be better to choose a "slower" language which has a more human-friendly semantics. Further, if there are some specific performance critical parts, those can always be implemented in another language. Just as a reference, in the 2016 ICFP programming contest, these were the languages used by the winners:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

None of them used a single language.