C# 不是解释性语言，尽管它使用中间语言 (IL)，但在执行之前会 JIT 为本机指令，因此它有一些相同的速度降低，但不是全部，但我敢打赌，如果您为 C# 或 C++ 构建了一个成熟的解释器，它的运行速度也会变慢。
需要明确的是，当我说“慢”时，这当然是一个相对术语。
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.
Google 的 Javascript Core8 速度非常快，并且以接近 C 的速度进行简单的优化：他们将对象数据模型作为固定的，并创建内部代码来访问它，就像本机编译程序的数据结构一样。当添加或删除新的变量或方法时，整个编译的代码将被丢弃并再次编译。
Deutsch/Schiffman 论文“Efficient Implement of the Smalltalk-80 System”对此技术进行了很好的解释。
为什么 PHP、Python 和 Ruby 不这样做的问题很容易回答： 该技术实施起来极其复杂。
而且只有 Google 有钱购买 JavaScript，因为基于浏览器的快速 JavaScript 解释器是其数十亿美元商业模式的基本需求。
All answers seem to miss the real important point here. It's the detail of how "interpreted" code is implemented.
Interpreted script languages are slower because their method, object, and global variable space model are dynamic. In my opinion, this is the real definition of script language, not the fact that it is interpreted. This requires many extra hash-table lookups on each access to a variable or method call. And it's the main reason why they are all terrible at multithreading and using a GIL (Global Interpreter Lock). This lookup is where most of the time is spent. It is a painful random memory lookup, which really hurts when you get an L1/L2 cache-miss.
Google's Javascript Core8 is so fast and targeting almost C speed for a simple optimization: they take the object data model as fixed and create internal code to access it like the data structure of a native compiled program. When a new variable or method is added or removed then the whole compiled code is discarded and compiled again.
The technique is well explained in the Deutsch/Schiffman paper "Efficient Implementation of the Smalltalk-80 System".
The question why PHP, Python and Ruby aren't doing this is pretty simple to answer: the technique is extremely complicated to implement.
And only Google has the money to pay for JavaScript because a fast browser-based JavaScript interpreter is the fundamental need of their billion-dollar business model.
Think of the interpeter as an emulator for a machine you don't happen to have
The short answer is that the compiled languages are executed by machine instructions whereas the interpreted ones are executed by a program (written in a compiled language) that reads either the source or a bytecode and then essentially emulates a hypothetical machine that would have run the program directly if the machine existed.
Think of the interpreted runtime as an emulator for a machine that you don't happen to actually have around at the moment.
This is obviously complicated by the JIT (Just In Time) compilers that Java, C#, and others have. In theory, they are just as good as "AOT" ("At One Time") compilers but in practice those languages run slower and are handicapped by needing to have the compiler around using up memory and time at the program's runtime. But if you say any of that here on SO be prepared to attract rabid JIT defenders who insist that there is no theoretical difference between JIT and AOT. If you ask them if Java and C# are as fast as C and C++, then they start making excuses and kind of calm down a little. :-)
So, C++ totally rules in games where the maximum amount of available computing can always be put to use.
On the desktop and web, information-oriented tasks are often done by languages with more abstraction or at least less compilation, because the computers are very fast and the problems are not computationally intensive, so we can spend some time on goals like time-to-market, programmer productivity, reliable memory-safe environments, dynamic modularity, and other powerful tools.
“足够快”，再加上使用 Python 等语言相对于 C 等语言所带来的生产力提高，应该足以成为考虑解释性语言的理由。另外，如果您确实需要速度，您始终可以用快速的 C 实现替换解释程序的某些部分。但话又说回来，首先测量并确定速度是否确实是问题所在，然后进行优化。
This is a good question, but should be formulated a little different in my opinion, for example: "Why are interpreted languages slower than compiled languages?"
I think it is a common misconception that interpreted languages are slow per se. Interpreted languages are not slow, but, depending on the use case, might be slower than the compiled version. In most cases interpreted languages are actually fast enough!
"Fast enough", plus the increase in productivity from using a language like Python over, for example, C should be justification enough to consider an interpreted language. Also, you can always replace certain parts of your interpreted program with a fast C implementation, if you really need speed. But then again, measure first and determine if speed is really the problem, then optimize.
In addition to the other answers there's optimization: when you're compiling a programme, you don't usually care how long it takes to compile - the compiler has lots of time to optimize your code. When you're interpreting code, it has to be done very quickly so some of the more clever optimizations might not be able to be made.
但解释性语言通常速度足够快，足以满足其使用目的。 Web 应用程序总是受到 IO（通常是数据库访问）的限制，这比任何解释器都要慢一个数量级。
A simple question, without any real simple answer. The bottom line is that all computers really "understand" is binary instructions, which is what "fast" languages like C are compiled into.
Then there are virtual machines, which understand different binary instructions (like Java and .NET) but those have to be translated on the fly to machine instructions by a Just-In-Compiler (JIT). That is almost as fast (even faster in some specific cases because the JIT has more information than a static compiler on how the code is being used.)
Then there are interpreted languages, which usually also have their own intermediate binary instructions, but the interpreter functions much like a loop with a large switch statement in it with a case for every instruction, and how to execute it. This level of abstraction over the underlying machine code is slow. There are more instructions involved, long chains of function calls in the interpreter to do even simple things, and it can be argued that the memory and cache aren't used as effectively as a result.
But interpreted languages are often fast enough for the purposes for which they're used. Web applications are invariably bound by IO (usually database access) which is an order of magnitude slower than any interpreter.
An Interpreted language is processed at runtime. Every line is read, analysed, and executed. Having to reprocess a line every time in a loop is what makes interpreted languages so slow. This overhead means that interpreted code runs between 5 - 10 times slower than compiled code. The interpreted languages like Basic or JavaScript are the slowest. Their advantage is not needing to be recompiled after changes and that is handy when you're learning to program.
The 5-10 times slower is not necessarily true for languages like Java and C#, however. They are interpreted, but the just-in-time compilers can generate machine language instructions for some operations, speeding things up dramatically (near the speed of a compiled language at times).
There is no such thing as an interpreted language. Any language can be implemented by an interpreter or a compiler. These days most languages have implementations using a compiler.
That said, interpreters are usually slower, because they need process the language or something rather close to it at runtime and translate it to machine instructions. A compiler does this translation to machine instructions only once, after that they are executed directly.
However, consider the following. I had a problem to solve. It took me 4 minutes to solve the problem in Python, and the program took 0.15 seconds to run. Then I tried to write it in C, and I got a runtime of 0.12 seconds, and it took me 1 hour to write it. All this because the practical way to solve problem in question was to use hashtables, and the hashtable dominated the runtime anyway.
Interpreted languages need to read and interpret your source code at execution time. With compiled code a lot of that interpretation is done ahead of time (at compilation time).
话虽如此，它们速度较慢，因为您的 cpu 在每“代码行”执行更多指令，因为许多指令都花在理解代码上，而不是执行该行语义建议的任何操作！
Very few contemporary scripting languages are "interpreted" these days; they're typically compiled on the fly, either into machine code or into some intermediate bytecode language, which is (more efficiently) executed in a virtual machine.
Having said that, they're slower because your cpu is executing many more instructions per "line of code", since many of the instructions are spent understanding the code rather than doing whatever the semantics of the line suggest!
This is the relevant idea in that post to your problem.
An execution by an interpreter is usually much less efficient then regular program execution. It happens because either every instruction should pass an interpretation at runtime or as in newer implementations, the code has to be compiled to an intermediate representation before every execution.
Interpreting code is slower than running the compiled code because the interpreter must analyze each statement in the program each time it is executed and then perform the desired action, whereas the compiled code just performs the action within a fixed context determined by the compilation. This run-time analysis is known as "interpretive overhead". Access to variables is also slower in an interpreter because the mapping of identifiers to storage locations must be done repeatedly at run-time rather than at compile time.
Interpreted program must be translated each time it is executed, there is a higher overhead. Thus, an interpreted language is generally more suited to ad hoc requests than predefined requests.
In Java though it is considered as an interpreted language, It uses JIT (Just-in-Time) compilation which mitigate the above issue by using a caching technique to cache the compiled bytecode.
The JIT compiler reads the bytecodes in many sections (or in full, rarely) and compiles them dynamically into machine code so the program can run faster. This can be done per-file, per-function or even on any arbitrary code fragment; the code can be compiled when it is about to be executed (hence the name "just-in-time"), and then cached and reused later without needing to be recompiled.
发布评论
评论（15）
本机程序使用为其运行的处理器编写的指令运行。
解释型语言就是“解释型”语言。某些其他形式的指令由运行时读取和解释，然后运行本机机器指令。
这样想吧。如果您可以用您的母语与某人交谈，那么通常比让口译员将您的语言翻译成其他语言以便听者理解要快。
请注意，我上面描述的是一种语言在解释器中运行时的情况。许多语言都有解释器，也有用于构建本机机器指令的本机链接器。速度降低（无论其大小可能是多少）仅适用于解释的上下文。
因此，说语言慢是稍微不正确的，而是它运行的上下文慢。
C# 不是解释性语言，尽管它使用中间语言 (IL)，但在执行之前会 JIT 为本机指令，因此它有一些相同的速度降低，但不是全部，但我敢打赌，如果您为 C# 或 C++ 构建了一个成熟的解释器，它的运行速度也会变慢。
需要明确的是，当我说“慢”时，这当然是一个相对术语。
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.
所有答案似乎都忽略了这里真正重要的一点。这是如何实现“解释”代码的细节。
解释型脚本语言速度较慢，因为它们的方法、对象和全局变量空间模型是动态的。在我看来，这是脚本语言的真正定义，而不是它被解释的事实。这需要在每次访问变量或方法调用时进行许多额外的哈希表查找。这就是为什么它们在多线程和使用 GIL（全局解释器锁）方面都很糟糕的主要原因。这个查找是花费大部分时间的地方。这是一个痛苦的随机内存查找，当您遇到 L1/L2 缓存未命中时，这真的很痛苦。
Google 的 Javascript Core8 速度非常快，并且以接近 C 的速度进行简单的优化：他们将对象数据模型作为固定的，并创建内部代码来访问它，就像本机编译程序的数据结构一样。当添加或删除新的变量或方法时，整个编译的代码将被丢弃并再次编译。
Deutsch/Schiffman 论文“Efficient Implement of the Smalltalk-80 System”对此技术进行了很好的解释。
为什么 PHP、Python 和 Ruby 不这样做的问题很容易回答：
该技术实施起来极其复杂。
而且只有 Google 有钱购买 JavaScript，因为基于浏览器的快速 JavaScript 解释器是其数十亿美元商业模式的基本需求。
All answers seem to miss the real important point here. It's the detail of how "interpreted" code is implemented.
Interpreted script languages are slower because their method, object, and global variable space model are dynamic. In my opinion, this is the real definition of script language, not the fact that it is interpreted. This requires many extra hash-table lookups on each access to a variable or method call. And it's the main reason why they are all terrible at multithreading and using a GIL (Global Interpreter Lock). This lookup is where most of the time is spent. It is a painful random memory lookup, which really hurts when you get an L1/L2 cache-miss.
Google's Javascript Core8 is so fast and targeting almost C speed for a simple optimization: they take the object data model as fixed and create internal code to access it like the data structure of a native compiled program. When a new variable or method is added or removed then the whole compiled code is discarded and compiled again.
The technique is well explained in the Deutsch/Schiffman paper "Efficient Implementation of the Smalltalk-80 System".
The question why PHP, Python and Ruby aren't doing this is pretty simple to answer:
the technique is extremely complicated to implement.
And only Google has the money to pay for JavaScript because a fast browser-based JavaScript interpreter is the fundamental need of their billion-dollar business model.
将解释器视为您没有的机器的模拟器。
简短的答案是，编译语言由机器指令执行，而解释语言由程序（用编译语言编写）执行，该程序读取源或字节码，然后本质上模拟一个假设的机器，如果该机器存在，该机器将直接运行该程序。
将解释运行时视为您目前实际上没有的机器的模拟器。
Java、C# 和其他语言的 JIT（Just In Time）编译器显然使这变得复杂。从理论上讲，它们与“AOT”（“一次”）编译器一样好，但实际上这些语言运行速度较慢，并且由于需要让编译器在程序运行时耗尽内存和时间而受到限制。但如果你在这里说任何这样的话，请准备好吸引狂热的 JIT 捍卫者，他们坚持认为 JIT 和 AOT 之间没有理论上的区别。如果你问他们 Java 和 C# 是否和 C 和 C++ 一样快，他们就会开始找借口，然后稍微平静下来。 :-)
因此，C++ 完全统治了游戏，始终可以使用最大数量的可用计算。
在桌面和网络上，面向信息的任务通常由更抽象或至少更少编译的语言来完成，因为计算机速度非常快，而且问题不是计算密集型的，因此我们可以花一些时间在诸如时间之类的目标上。 -市场、程序员生产力、可靠的内存安全环境、动态模块化和其他强大的工具。
Think of the interpeter as an emulator for a machine you don't happen to have
The short answer is that the compiled languages are executed by machine instructions whereas the interpreted ones are executed by a program (written in a compiled language) that reads either the source or a bytecode and then essentially emulates a hypothetical machine that would have run the program directly if the machine existed.
Think of the interpreted runtime as an emulator for a machine that you don't happen to actually have around at the moment.
This is obviously complicated by the JIT (Just In Time) compilers that Java, C#, and others have. In theory, they are just as good as "AOT" ("At One Time") compilers but in practice those languages run slower and are handicapped by needing to have the compiler around using up memory and time at the program's runtime. But if you say any of that here on SO be prepared to attract rabid JIT defenders who insist that there is no theoretical difference between JIT and AOT. If you ask them if Java and C# are as fast as C and C++, then they start making excuses and kind of calm down a little. :-)
So, C++ totally rules in games where the maximum amount of available computing can always be put to use.
On the desktop and web, information-oriented tasks are often done by languages with more abstraction or at least less compilation, because the computers are very fast and the problems are not computationally intensive, so we can spend some time on goals like time-to-market, programmer productivity, reliable memory-safe environments, dynamic modularity, and other powerful tools.
这是一个很好的问题，但在我看来应该表述得有点不同，例如：“为什么解释语言比编译语言慢？”
我认为解释语言本身很慢是一个常见的误解。解释型语言并不慢，但根据使用情况，可能会慢于编译版本。在大多数情况下，解释语言实际上足够快！
“足够快”，再加上使用 Python 等语言相对于 C 等语言所带来的生产力提高，应该足以成为考虑解释性语言的理由。另外，如果您确实需要速度，您始终可以用快速的 C 实现替换解释程序的某些部分。但话又说回来，首先测量并确定速度是否确实是问题所在，然后进行优化。
This is a good question, but should be formulated a little different in my opinion, for example: "Why are interpreted languages slower than compiled languages?"
I think it is a common misconception that interpreted languages are slow per se. Interpreted languages are not slow, but, depending on the use case, might be slower than the compiled version. In most cases interpreted languages are actually fast enough!
"Fast enough", plus the increase in productivity from using a language like Python over, for example, C should be justification enough to consider an interpreted language. Also, you can always replace certain parts of your interpreted program with a fast C implementation, if you really need speed. But then again, measure first and determine if speed is really the problem, then optimize.
除了其他答案之外，还有优化：当您编译程序时，您通常不关心编译需要多长时间 - 编译器有很多时间来优化您的代码。当您解释代码时，必须非常快地完成，因此可能无法进行一些更聪明的优化。
In addition to the other answers there's optimization: when you're compiling a programme, you don't usually care how long it takes to compile - the compiler has lots of time to optimize your code. When you're interpreting code, it has to be done very quickly so some of the more clever optimizations might not be able to be made.
循环 a 100 次，循环内容被解释 100 次为低级代码。
不缓存、不重用、不优化。
简而言之，编译器将一次解释为低级代码
编辑，在注释之后：
Loop a 100 times, the contents of the loop are interpreted 100 times into low level code.
Not cached, not reused, not optimised.
In simple terms, a compiler interprets once into low level code
Edit, after comments:
一个简单的问题，没有任何真正简单的答案。最重要的是，所有计算机真正“理解”的是二进制指令，这就是像 C 这样的“快速”语言被编译成的指令。
然后是虚拟机，它可以理解不同的二进制指令（例如 Java 和 .NET），但这些指令必须由即时编译器 (JIT) 即时转换为机器指令。这几乎一样快（在某些特定情况下甚至更快，因为 JIT 比静态编译器拥有更多关于如何使用代码的信息。）
然后是解释语言，它们通常也有自己的中间二进制指令，但解释器功能很像一个循环，里面有一个大的 switch 语句，每个指令都有一个 case，以及如何执行它。这种对底层机器代码的抽象级别很慢。解释器中涉及更多的指令、长长的函数调用链来完成甚至简单的事情，并且可以说内存和缓存没有得到有效的使用。
但解释性语言通常速度足够快，足以满足其使用目的。 Web 应用程序总是受到 IO（通常是数据库访问）的限制，这比任何解释器都要慢一个数量级。
A simple question, without any real simple answer. The bottom line is that all computers really "understand" is binary instructions, which is what "fast" languages like C are compiled into.
Then there are virtual machines, which understand different binary instructions (like Java and .NET) but those have to be translated on the fly to machine instructions by a Just-In-Compiler (JIT). That is almost as fast (even faster in some specific cases because the JIT has more information than a static compiler on how the code is being used.)
Then there are interpreted languages, which usually also have their own intermediate binary instructions, but the interpreter functions much like a loop with a large switch statement in it with a case for every instruction, and how to execute it. This level of abstraction over the underlying machine code is slow. There are more instructions involved, long chains of function calls in the interpreter to do even simple things, and it can be argued that the memory and cache aren't used as effectively as a result.
But interpreted languages are often fast enough for the purposes for which they're used. Web applications are invariably bound by IO (usually database access) which is an order of magnitude slower than any interpreter.
来自 about.com：
然而，对于 Java 和 C# 等语言来说，慢 5-10 倍并不一定成立。它们被解释，但是即时编译器可以生成机器语言某些操作的指令，显着加快速度（有时接近编译语言的速度）。
From about.com:
The 5-10 times slower is not necessarily true for languages like Java and C#, however. They are interpreted, but the just-in-time compilers can generate machine language instructions for some operations, speeding things up dramatically (near the speed of a compiled language at times).
不存在解释性语言这样的东西。任何语言都可以通过解释器或编译器来实现。如今，大多数语言都使用编译器来实现。
也就是说，解释器通常速度较慢，因为它们需要在运行时处理语言或与其相当接近的语言并将其翻译为机器指令。编译器只将机器指令翻译一次，然后直接执行。
There is no such thing as an interpreted language. Any language can be implemented by an interpreter or a compiler. These days most languages have implementations using a compiler.
That said, interpreters are usually slower, because they need process the language or something rather close to it at runtime and translate it to machine instructions. A compiler does this translation to machine instructions only once, after that they are executed directly.
是的，解释语言很慢......
但是，请考虑以下因素。我有一个问题需要解决。我用Python解决这个问题花了4分钟，程序运行了0.15秒。然后我尝试用C写它，我得到了0.12秒的运行时间，我花了1个小时才写完。所有这一切都是因为解决相关问题的实际方法是使用哈希表，而哈希表无论如何都主导了运行时。
Yeah, interpreted languages are slow...
However, consider the following. I had a problem to solve. It took me 4 minutes to solve the problem in Python, and the program took 0.15 seconds to run. Then I tried to write it in C, and I got a runtime of 0.12 seconds, and it took me 1 hour to write it. All this because the practical way to solve problem in question was to use hashtables, and the hashtable dominated the runtime anyway.
解释型语言需要在执行时读取并解释源代码。对于编译后的代码，很多解释都是提前完成的（在编译时）。
Interpreted languages need to read and interpret your source code at execution time. With compiled code a lot of that interpretation is done ahead of time (at compilation time).
如今，很少有当代脚本语言被“解释”。它们通常被即时编译成机器代码或某种中间字节码语言，这些语言在虚拟机中（更有效地）执行。
话虽如此，它们速度较慢，因为您的 cpu 在每“代码行”执行更多指令，因为许多指令都花在理解代码上，而不是执行该行语义建议的任何操作！
Very few contemporary scripting languages are "interpreted" these days; they're typically compiled on the fly, either into machine code or into some intermediate bytecode language, which is (more efficiently) executed in a virtual machine.
Having said that, they're slower because your cpu is executing many more instructions per "line of code", since many of the instructions are spent understanding the code rather than doing whatever the semantics of the line suggest!
阅读此解释语言的优点和缺点
这是该帖子中的相关想法对你的问题。
Read this Pros And Cons Of Interpreted Languages
This is the relevant idea in that post to your problem.
出于同样的原因，通过翻译交谈比用母语交谈要慢。或者，用字典阅读。翻译需要时间。
更新：不，我没有看到我的答案与已接受的答案在某种程度上相同;-)
For the same reason that it's slower to talk via translator than in native language. Or, reading with dictionary. It takes time to translate.
Update: no, I didn't see that my answer is the same as the accepted one, to a degree ;-)
维基百科说，
请参阅此 IBM 文档，
在Java中，虽然它被认为是一种解释性语言，但它使用JIT（只是-in-Time）编译，通过使用缓存技术来缓存已编译的字节码来缓解上述问题。
Wikipedia says,
Refer this IBM doc,
In Java though it is considered as an interpreted language, It uses JIT (Just-in-Time) compilation which mitigate the above issue by using a caching technique to cache the compiled bytecode.