字节码与解释码

当你把东西编译成字节码时,你有机会首先执行一系列昂贵的高级优化。您将字节码设计为 非常

因此,速度的提高可能是相当可观的——不仅您在运行时跳过了整个词法分析阶段,而且您还有更多的机会应用优化并生成更好的机器代码。

你可以看到一个相当好的推动。然而,有很多因素。你不能说编译的代码总是比解释的代码快10倍,或者字节码比解释的代码快n倍。

例如,因素包括语言的复杂性和冗长性。如果语言中的一个关键字是多个字符,而字节码是一个字符,那么加载字节码并跳转到处理该字节码的例程,应该比读取关键字字符串快得多,然后找出要去的地方。但是,如果您正在解释一种具有一个字节关键字的外来语言,这种差异可能就不那么明显了。

我在实践中看到了这种性能的提升,所以对你来说可能是值得的。另外,写这样的东西很有趣,让你感受到语言解释器和编译器是如何工作的,这会让你成为一个更好的程序员。

现在有没有主流的“解释器”没有真正编译他们的代码?(字节码或类似的东西)

坚持这个例子,很明显Perl不能比优化良好的C代码更快,因为它是用C编写的。实际上,对于通常使用Perl所做的大多数事情(如文本处理),它将尽可能快地用C编写,并且数量级的代码更容易编写。另一方面,我当然不会尝试直接用Perl编写高性能的数学例程。

此外,许多“经典”解释器还包括lex/parse阶段和执行阶段。

例如,考虑执行一个Python脚本。当你这样做的时候,你就有了将程序文本转换成内部解释器数据结构的所有相关成本,然后执行这些数据结构。

现在将其与执行编译的Python脚本.pyc文件进行对比。在这里,lex和parse阶段完成了,您只需要运行内部解释器。

但是,如果你考虑,比如说,一个经典的基本解释器,这些解释器通常不会存储原始文本,而是存储一个标记形式,并在你“列出”时重新创建程序文本。这里的字节码更粗糙(这里没有虚拟机),但是执行时会跳过一些文本处理。当你进入这一行并按回车键时,一切都结束了。

这是根据你的虚拟机。一些速度更快的虚拟机(JVM)正在接近C代码的速度。那么,与C相比,您的解释代码的运行速度有多快?

不要认为如果你把解释后的代码转换成字节码,它的运行速度会和Java一样快(接近C速度),已经有很多年的性能提升了,但是你应该会看到显著的速度提升。

Emacs 已移植到字节码中,性能得到提高。也许值得你看看。

我从来没有注意到Vim脚本的速度慢到足以引起注意。假设脚本主要调用编辑器核心中实现的内置、本机代码、操作(正则表达式、块操作等),那么即使脚本中的“粘合逻辑”速度提高10倍也无关紧要。

不过,分析是唯一可以确定的方法。