8

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

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

4

6 回答 6

9

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

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

于 2009-02-10T22:55:19.067 回答
3

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

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

我已经在实践中看到了这种性能提升，所以这对你来说可能是值得的。此外，编写这样的东西很有趣，让您了解语言解释器和编译器的工作原理，这将使您成为更好的编码器。

于 2009-02-10T23:01:26.290 回答
1

这些天实际上有没有真正编译他们的代码的主流“解释器”？（无论是字节码还是类似的东西。）

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

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

于 2009-02-11T00:25:10.707 回答
1

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

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

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

但是，如果您考虑使用经典的 BASIC 解释器，它们通常从不存储原始文本，而是存储标记化的形式并在您执行“LIST”时重新创建程序文本。这里的字节码要粗略得多（您实际上并没有虚拟机），但是您的执行会跳过一些文本处理。当您输入该行并按 ENTER 时，这一切都完成了。

于 2009-02-11T00:26:02.983 回答
0

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

不要认为如果将解释代码转换为字节码，它的运行速度会与 Java 一样快（接近 C 速度），性能提升已经持续多年，但您应该会看到显着的速度提升。

Emacs已被移植到具有更高性能的字节码中。可能值得你看看。

于 2009-02-11T00:09:55.033 回答
0

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

尽管如此，剖析是真正确定的唯一方法。

于 2009-02-11T00:21:12.840 回答