Javascript引擎通常用于将源代码转换为字节码，然后将字节码转换为本地代码。
1) 为什么要转换字节码？源码直接转化原生代码性能差？ 2)如果源代码很简单(例如a+b函数)，源代码直接转换native代码好吗？
最佳答案
复杂性和可移植性。
从源代码转换为某种目标代码，无论是虚拟机的字节码还是真实机器的机器代码，都是一个复杂的过程。 字节码更接近地模仿大多数真实机器的行为，因此更容易使用:更好地优化代码以使其运行得更快，转换为机器代码以获得更大的提升，甚至转换为其他格式如果情况需要的话。
因此，编写一个前端通常会更容易，其唯一的工作是将源代码转换为字节码(或其他一些中间语言 )，然后是一个处理中间语言的后端:优化它，输出机器代码，以及所有这些爵士乐。 更传统的 C 语言编译器已经这样做了很长时间。Java 可以被认为是这一原则的不寻常应用:它的构建过程通常以中间表示形式(即 Java 字节码)停止，然后开发人员将其发送出去，以便 JVM 可以在用户运行它时“完成工作”。
除了使代码更易于使用之外，这种工作方式还有两大好处。 第一个大优点是您可以重用后端来使用其他语言。这对于 JavaScript(它没有标准化的后端)来说并不重要，但这就是 LLVM 和 GCC 这样的项目最终发展到涵盖如此多不同语言的方式。编写前端是一项艰苦的工作，但假设我为 Mozilla 的 JavaScript 后端制作了一个 Lua 前端。然后我可以利用 Mozilla 对该后端所做的所有优化工作。这节省了我很多工作。
另一大优势是您可以重用前端来与更多机器一起工作。这确实对 JavaScript 具有实际意义。如果我要编写一个 JavaScript 解释器，我可能会为 x86(大多数 PC 使用的架构)编写第一个后端，因为那是我可能进行开发工作的地方。但大多数手机不使用基于 x86 的架构 - ARM 现在更常见 - 所以如果我想在手机上快速运行，我需要添加 ARM 后端。但我可以做到这一点，而不必重写整个前端，所以我再次为自己节省了很多工作。如果我想在 Wii U(或上一代游戏机，或更旧的 Mac)上运行，那么我需要 POWER 后端，但同样，我可以在不重写前端的情况下做到这一点。
底线是，虽然进行两次转换似乎更复杂，但从长远来看，它实际上变得更容易。这是软件设计中有时会出现的奇怪且不直观的事情之一，但好处是真实的。
关于javascript - 为什么要转换 SpiderMonkey & JSC 中的字节码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26423104/