我认为很明显，如果我们只是为了解释一个代码，那么编译相同的代码并执行它会更快。我无法理解的是jit编译器如何获得比服务器上的解释语言更好的性能（通常），在这些服务器上有数千个连接 - 是否需要为每个连接重新编译代码？如果有变化怎么办？在此先感谢您帮助我更好地理解这一点。
答案 0 :(得分：0)
任何编程语言都可以被解释或编译，甚至两者都可以。用编程语言编写的程序的性能受许多因素的影响，其中只有一个因素是是否使用了解释器，编译器或JIT编译器。动态类型，动态调度和后期绑定等一些功能很昂贵，使用它们的程序会更慢。语言语法本身会影响性能。口译员可以使用静态优化，动态优化，离线配置文件指南优化，在线配置文件引导优化或硬件特定优化。
然而，为了简化事情。我们可以比较解释器和JIT编译器如下。解释函数意味着执行以下步骤：解析每个语句，优化它，发出机器代码，最后执行它。编译函数的JIT意味着：解析所有语句，优化它们，发出机器代码，最后执行它们。
有两个重要的区别。首先，解释器解析高级语言语法，而JIT编译器解析中级语言语法。因此，JIT编译器可以更快地执行此步骤。其次，JIT编译器可以通过同时考虑所有语句来更好地优化代码，而纯解释器一次优化一个语句。因此，使用JIT编译器时，发出的二进制代码的性能会更好。
正如您所看到的，与口译员相比，JIT编译器提供了更多的性能机会。无论您是在客户端还是在服务器上，这都适用。请注意，一旦函数被JIT编译，它就不必再次进行JIT编译。因此，只有第一个用户请求才会产生编译开销。所有其他人都全速处理。
答案 1 :(得分：0)
我认为很明显，如果我们花时间来解释代码，那么编译和执行相同的代码会更快。
嗯，不是（或至少是“何时”）？
需要将源代码转换为CPU真正理解的东西。有两个主要注意事项：
a）完成这项工作。工作是否提前/在执行任何操作之前完成了，以便在程序运行时没有人关心它？还是在每个小片段（例如，源代码声明）执行之前完成；或者是其他东西？请注意，这项工作可以（并且经常）分解并在多个地方完成（例如，“ ”进行编译和优化以提前为VM生成字节代码，然后进行更多工作以将字节代码转换为CPU可以在运行时理解“）。
b）工作完成得如何。转换涉及优化，某些优化相对较快（“窥孔”），而某些优化则非常昂贵。例如，假设一个程序员在某个地方使用int foo = 4;创建了一个全局变量，然后另一个程序员在其他地方编写了return foo * 2;；因此，在优化过程中，您希望搜索数百万行代码，以证明从未修改全局变量，因为也许可以将return foo *2;转换为更快的return 8;。再举一个例子，仅尝试以最佳方式找出寄存器分配（哪些变量进入哪个寄存器）是一个已知的“ NP完全”问题。
我无法理解的是，与服务器上具有数千个连接的解释型语言相比，jit编译器在一般情况下如何实现更好的性能-是否需要为每个连接重新编译代码
纯口译员的表现非常差。每次执行每一个小片段（每个源代码语句，或者每个字节代码（如果已预先编译）时），都会执行将代码转换为CPU可以理解的工作，即使该工作已经完成做过数百万次而且由于它工作在这么小的微小部分上，因此几乎不可能进行所有优化。
纯JIT的性能非常差。即使第一次执行一小段代码（每组线性的源代码语句，或者线性组的字节代码（如果已预先编译）），即使将代码转换为CPU可以理解的工作，即使第一次执行这项工作只需要一次；而且由于它只能处理很小的部分，因此不可能进行最优化。
为避免某些问题；大多数现代VM使用“混合解释和JIT”方法，例如（例如）它们可能在第一次执行代码时解释代码（以避免浪费JIT），而在第二次执行代码时切换到JIT（假设是否有某种情况）执行两次可能会执行多次，从而避免了“将代码转换为CPU可以理解的数百万次的工作（如果最终要执行数百万次）”的问题。但是...
“混合解释和JIT”的性能不佳。它仍然无法进行任何昂贵的优化，仍然无法在执行代码之前将其转换为本机（并避免出现“每次启动程序时都进行转换”的问题）等。
本机代码编译器往往只会为您提供适当的性能。它仍然远未达到完美。
要了解的重要一点是性能是相对的。如果一件事的性能较差（与理想的优化程序相比），而另一件事的性能较差（与理想的优化程序相比）；那么“坏”比“非常坏”好。通过更改参考点（例如，将所有内容与使用药物的猴子进行比较），您可以说提前编译为本地可以提供非常好的性能（与使用药物的猴子相比），“混合解释和JIT”可以提供非常好的性能（相比对猴子来说，纯JIT可以提供良好的性能（相比之下，对猴子来说是毒品），而纯粹解释型的JIT则具有足够的性能（与猴子相比，对药品而言）。