WebAssembly 系列（五）为何 WebAssembly 更快？

做者：Lin Clark

编译：胡子大哈

翻译原文：huziketang.com/blog/posts/…

英文原文：What makes WebAssembly fast?

转载请注明出处，保留原文连接以及做者信息

---

本文做者：Lin Clark
英文原文：What makes WebAssembly fast?

本文是关于 WebAssembly 系列的第五篇文章（本系列共六篇文章）。若是你没有读先前文章的话，建议先读这里。若是对 WebAssembly 没概念，建议先读这里（中文文章）。

上一篇文章中，我介绍了如何编写 WebAssembly 程序，也表达了我但愿看到更多的开发者在本身的工程中同时使用 WebAssembly 和 JavaScript 的期许。

开发者们没必要纠结于到底选择 WebAssembly 仍是 JavaScript，已经有了 JavaScript 工程的开发者们，但愿能把部分 JavaScript 替换成 WebAssembly 来尝试使用。

例如，正在开发 React 程序的团队能够把调节器代码（即虚拟 DOM）替换成 WebAssembly 的版本。而对于你的 web 应用的用户来讲，他们就跟之前同样使用，不会发生任何变化，同时他们还能享受到 WebAssembly 所带来的好处——快。

而开发者们选择替换为 WebAssembly 的缘由正是由于 WebAssembly 比较快。那么为何它执行的快呢？咱们来一块儿了解一下。

当前的 JavaScript 性能如何？

在咱们了解 JavaScript 和 WebAssembly 的性能区别以前，须要先理解 JS 引擎的工做原理。

下面这张图片介绍了性能使用的大概分布状况。

JS 引擎在图中各个部分所花的时间取决于页面所用的 JavaScript 代码。图表中的比例并不表明真实状况下的确切比例状况。

图中的每个颜色条都表明了不一样的任务：

• Parsing——表示把源代码变成解释器能够运行的代码所花的时间；
• Compiling + optimizing——表示基线编译器和优化编译器花的时间。一些优化编译器的工做并不在主线程运行，不包含在这里。
• Re-optimizing——当 JIT 发现优化假设错误，丢弃优化代码所花的时间。包括重优化的时间、抛弃并返回到基线编译器的时间。
• Execution——执行代码的时间
• Garbage collection——垃圾回收，清理内存的时间

这里注意：这些任务并非离散执行的，或者按固定顺序依次执行的。而是交叉执行，好比正在进行解析过程时，其余一些代码正在运行，而另外一些正在编译。

这样的交叉执行给早期 JavaScript 带来了很大的效率提高，早期的 JavaScript 执行相似于下图，各个过程顺序进行：

早期时，JavaScript 只有解释器，执行起来很是慢。当引入了 JIT 后，大大提高了执行效率，缩短了执行时间。

JIT 所付出的开销是对代码的监视和编译时间。JavaScript 开发者能够像之前那样开发 JavaScript 程序，而一样的程序，解析和编译的时间也大大缩短。这就使得开发者们更加倾向于开发更复杂的 JavaScript 应用。

同时，这也说明了执行效率上还有很大的提高空间。

WebAssembly 对比

下面是 WebAssembly 和典型的 web 应用的近似对比图：

各类浏览器处理上图中不一样的过程，有着细微的差异，我用 SpiderMonkey 做为模型来说解不一样的阶段：

文件获取

这一步并无显示在图表中，可是这看似简单地从服务器获取文件这个步骤，却会花费很长时间。

WebAssembly 比 JavaScript 的压缩率更高，因此文件获取也更快。即使经过压缩算法能够显著地减少 JavaScript 的包大小，可是压缩后的 WebAssembly 的二进制代码依然更小。

这就是说在服务器和客户端之间传输文件更快，尤为在网络很差的状况下。

解析

当到达浏览器时，JavaScript 源代码就被解析成了抽象语法树。

浏览器采用懒加载的方式进行，只解析真正须要的部分，而对于浏览器暂时不须要的函数只保留它的桩。

解析事后 AST （抽象语法树）就变成了中间代码（叫作字节码），提供给 JS 引擎编译。

而 WebAssembly 则不须要这种转换，由于它自己就是中间代码。它要作的只是解码而且检查确认代码没有错误就能够了。

编译和优化

上一篇关于 JIT 的文章中，我有介绍过，JavaScript 是在代码的执行阶段编译的。由于它是弱类型语言，当变量类型发生变化时，一样的代码会被编译成不一样版本。

不一样浏览器处理 WebAssembly 的编译过程也不一样，有些浏览器只对 WebAssembly 作基线编译，而另外一些浏览器用 JIT 来编译。

不论哪一种方式，WebAssembly 都更贴近机器码，因此它更快，使它更快的缘由有几个：

1. 在编译优化代码以前，它不须要提早运行代码以知道变量都是什么类型。
2. 编译器不须要对一样的代码作不一样版本的编译。
3. 不少优化在 LLVM 阶段就已经作完了，因此在编译和优化的时候没有太多的优化须要作。

重优化

有些状况下，JIT 会反复地进行“抛弃优化代码<->重优化”过程。

当 JIT 在优化假设阶段作的假设，执行阶段发现是不正确的时候，就会发生这种状况。好比当循环中发现本次循环所使用的变量类型和上次循环的类型不同，或者原型链中插入了新的函数，都会使 JIT 抛弃已优化的代码。

反优化过程有两部分开销。第一，须要花时间丢掉已优化的代码而且回到基线版本。第二，若是函数依旧频繁被调用，JIT 可能会再次把它发送到优化编译器，又作一次优化编译，这是在作无用功。

在 WebAssembly 中，类型都是肯定了的，因此 JIT 不须要根据变量的类型作优化假设。也就是说 WebAssembly 没有重优化阶段。

执行

本身也能够写出执行效率很高的 JavaScript 代码。你须要了解 JIT 的优化机制，例如你要知道什么样的代码编译器会对其进行特殊处理（JIT 文章里面有提到过）。

然而大多数的开发者是不知道 JIT 内部的实现机制的。即便开发者知道 JIT 的内部机制，也很难写出符合 JIT 标准的代码，由于人们一般为了代码可读性更好而使用的编码模式，偏偏不合适编译器对代码的优化。

加之 JIT 会针对不一样的浏览器作不一样的优化，因此对于一个浏览器优化的比较好，极可能在另一个浏览器上执行效率就比较差。

正是由于这样，执行 WebAssembly 一般会比较快，不少 JIT 为 JavaScript 所作的优化在 WebAssembly 并不须要。另外，WebAssembly 就是为了编译器而设计的，开发人员不直接对其进行编程，这样就使得 WebAssembly 专一于提供更加理想的指令（执行效率更高的指令）给机器就行了。

执行效率方面，不一样的代码功能有不一样的效果，通常来说执行效率会提升 10% - 800%。

垃圾回收

JavaScript 中，开发者不须要手动清理内存中不用的变量。JS 引擎会自动地作这件事情，这个过程叫作垃圾回收。

但是，当你想要实现性能可控，垃圾回收可能就是个问题了。垃圾回收器会自动开始，这是不受你控制的，因此颇有可能它会在一个不合适的时机启动。目前的大多数浏览器已经能给垃圾回收安排一个合理的启动时间，不过这仍是会增长代码执行的开销。

目前为止，WebAssembly 不支持垃圾回收。内存操做都是手动控制的（像 C、C++同样）。这对于开发者来说确实增长了些开发成本，不过这也使代码的执行效率更高。

总结

WebAssembly 比 JavaScript 执行更快是由于：

• 文件抓取阶段，WebAssembly 比 JavaScript 抓取文件更快。即便 JavaScript 进行了压缩，WebAssembly 文件的体积也比 JavaScript 更小；
• 解析阶段，WebAssembly 的解码时间比 JavaScript 的解析时间更短；
• 编译和优化阶段，WebAssembly 更具优点，由于 WebAssembly 的代码更接近机器码，而 JavaScript 要先经过服务器端进行代码优化。
• 重优化阶段，WebAssembly 不会发生重优化现象。而 JS 引擎的优化假设则可能会发生“抛弃优化代码<->重优化”现象。
• 执行阶段，WebAssembly 更快是由于开发人员不须要懂太多的编译器技巧，而这在 JavaScript 中是须要的。WebAssembly 代码也更适合生成机器执行效率更高的指令。
• 垃圾回收阶段，WebAssembly 垃圾回收都是手动控制的，效率比自动回收更高。

这就是为何在大多数状况下，同一个任务 WebAssembly 比 JavaScript 表现更好的缘由。

可是，还有一些状况 WebAssembly 表现的会不如预期；同时 WebAssembly 的将来也会朝着使 WebAssembly 执行效率更高的方向发展。这些我会在下一篇文章《WebAssembly 系列（六）WebAssembly 的如今与将来》中介绍。

---

我最近正在写一本《React.js 小书》，对 React.js 感兴趣的童鞋，欢迎指点。