Vim 字节码与解释码

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

---

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

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

---

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

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

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

---

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

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

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

---

已被移植到字节码中，性能有所提高。可能值得一看。

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

---

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

现在真的有主流的“解释器”没有编译他们的代码吗？（可以是字节码或类似的东西。）

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

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

此外，许多“经典”解释器还包括执行过程中的lex/parse阶段

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

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

---

但是，如果你认为，一个经典的基本解释器，这些通常不存储原始文本，而是存储一个标记化的表单，并在你做“列表”时重新创建程序文本。这里的字节码要粗糙得多（这里实际上没有虚拟机），但执行过程会跳过一些文本处理。当您输入该行并按enter键时，所有操作都已完成。

从何处开始？我在大学时写过一个编译器，但它是为一种非常简单的语言编写的，我甚至无法想象编写一个字节码解释器。大多数困难的工作首先将是编译字节码——之后，你的解释器将仅仅是一个美化的状态机。只需直接使用字节码索引到例程数组中即可。如果你想JIT它，它只会变得很难。我不能给你当前的建议-我在80年代的某个时候写了一个编译成字节码的编译器，那是在俄亥俄科学C1P上的6502汇编程序中。所以，事情可能已经发生了变化；）字节码被解释。源代码和字节码会更好。对我来说，源代码意味着要编译。@Whaledawg字节码也可以编译。基于Java（最广泛使用的基于字节码的平台）的功能，你完全错了。在源代码编译期间很少进行优化；大部分优化都是由JIT编译器完成的，而JVM是一种基于堆栈的体系结构，根本无法很好地映射到现实世界的指令集。他不是问Java，而是问一般的字节码。从解释器到字节码/JIT提供了进行早期优化和选择与机器语言很好映射的字节码的机会。Java的设计者有理由选择他们所选择的字节码，但这不是唯一的方法。Ruby 1.8（MRI）使用AST walker，而不是字节码。但它仍然可以进行完整的解析。