字节码解读

Question

我记得一位教授曾经说过，解释后的代码比编译的代码慢了10倍。解释和字节码之间的速度差异是多少？ （假设字节码不是JIT编译的）

我问，因为有些人一直在努力将vim脚本编译成字节码，我只是想知道会有什么样的性能提升。

Answer 1

当您将事物编译为字节码时，您有机会首先执行一系列昂贵的高级优化。您可以将字节代码非常设计为轻松编译为机器代码，并提前运行所有优化和流分析。

因此，速度提升可能非常大 - 不仅在运行时跳过整个lexing / parsing阶段，而且还有更多机会应用优化并生成更好的机器代码。

Answer 2

你可以看到相当不错的提升。但是，有很多因素。你不能只说已编译的代码总是比解释代码快10倍，或者字节代码比解释代码快n倍。

因素包括语言的复杂性和冗长性。如果语言中的关键字是几个字符，并且字节码是1，那么加载字节码并跳转到处理该字节码的例程比读取关键字字符串要快得多，然后弄清楚去哪儿。但是，如果您正在解释具有单字节关键字的外来语言之一，则差异可能不太明显。

我在实践中看到了这种性能提升，所以它可能对你有所帮助。此外，编写这样的东西很有趣，让您了解语言解释器和编译器的工作方式，这将使您成为更好的编码器。

Answer 3

这些天实际上是否有任何主流“解释器”实际上没有编译他们的代码？ （要么字节码或类似的东西。）

例如，当您使用直接从其源代码使用Perl程序时，它首先要做的是将源代码编译成语法树，然后对其进行优化并用于执行程序。在正常情况下，与实际运行程序的时间相比，编译时间很短。

坚持这个例子，显然Perl不能比经过优化的C代码快，因为它是用C语言编写的。在实践中，对于你通常用Perl做的大多数事情（比如文本处理），它会一样快因为你可以在C中合理地编码它，并且更容易编写数量级。另一方面，我当然不会尝试直接在Perl中编写高性能的数学例程。

Answer 4

此外，许多“经典”解释器还包括lex / parse阶段以及执行​​。

例如，考虑执行Python脚本。当您这样做时，您将获得与将程序文本转换为内部解释器数据结构相关的所有成本，然后执行这些成本。

现在将执行已编译的Python脚本与.pyc文件进行对比。这里，完成了lex和parse阶段，你只拥有内部解释器的运行时。

但是，如果你考虑一个经典的BASIC解释器，它们通常永远不会存储原始文本，而是存储一个标记化的表单，并在你执行“LIST”时重新创建程序文本。这里的字节代码比较粗糙（你这里没有真正的虚拟机），但你的执行会跳过一些文本处理。当你输入该行并点击ENTER时，这就完成了。

Answer 5

根据您的虚拟机。一些较快的虚拟机（JVM）正在接近C代码的速度。那么与C相比，你的解释代码的运行速度有多快？

不要以为如果将解释后的代码转换为ByteCode，它将以尽可能快的速度运行Java（接近C速度），已经有多年的性能提升，但你应该看到显着的速度提升。

Emacs已被移植到字节码中，性能提升。可能值得一看。

Answer 6

我从来没有注意到一个足够慢的Vim脚本。假设一个脚本主要调用在编辑器核心中实现的内置，本机代码，操作（正则表达式，块操作等），即使脚本中的“胶合逻辑”加速10倍也是微不足道的。

尽管如此，分析是唯一可以确定的方法。