图说 WebAssembly（五）：高性能缘由

本文是图说 WebAssembly 系列文章的第五篇。若是您还未阅读以前的文章，建议您从第一篇入手。

在上一篇文章中，咱们说到了使用 WebAssembly 和 JavaScript 并非两选一的选择。咱们并不但愿太多开发者只使用 WebAssembly 。

咱们但愿开发者能够把部分 JavaScript 代码替换为 WebAssembly 。

例如，React 团队能够把虚拟 DOM 改用 WebAssembly 来实现。这样的话，使用 React 的开发者也不须要作任何适配，可是它们却能得到更高性能。

可以促使 React 团队这么作的缘由最多是 WebAssembly 的高性能。可是究竟是什么使它有高性能呢？

JS 性能分析

在咱们理解 JavaScript 和 WebAssembly 之间的性能差别缘由以前，咱们须要先理解 JavaScript 引擎所作的工做。

下图给了一个粗糙的描述，归纳了当前 JS 应用的启动性能。

JS 引擎在这些任务上所耗费的时间取决于页面所用的 JS 代码。该图并非用来准确的衡量其性能的。相反，它是一种高度抽象的模型，用来比较实现相同功能的 JavaScript 和 WebAssembly 之间的性能差别。

图中的每一块表示该任务所耗费的时间。

• 解析：把 JavaScript 源码解析为解释器可以运行的代码的时间。
• 编译+优化：基准编译器和优化编译器所耗费的时间。优化编译器的部分优化工做并非在主线程上进行的，这部分耗费的时间不包含在这里。
• 从新优化：当假设不成立时，JIT 做出从新调整所耗费的时间，包括从新优化和回退到基准代码的时间。
• 执行：运行代码耗费的时间。
• 垃圾回收：清理内存耗费的时间。

要注意的是，这些过程并不会以离散块或者特定的顺序发生。相反，它们是交叉进行的。
可能会解析完一小段，就会运行一段，而后编译一段；接着解析更多代码，而后执行更多代码等等。

这种分段交叉进行的设计相比早期的 JavaScript 来讲是一种很大的性能提高，早期的 JavaScript 执行更像是下图中的情形。

在最开始的时候，只有解析器来跑 JavaScript ，执行速度是至关慢的。当引入 JIT 后，执行速度获得了大幅提高。

固然，引入 JIT 的代价就是在监视器和编译器上投入了更多资源。
若是开发者仍是按照之前的方式来编写 JavaScript 应用，那么其实解析和编译时间是很小的。
只不过随着性能提高，开发者开发出了更大型的 JavaScript 应用，对性能要求又变高了。

所以，性能仍是有提高空间的。

WebAssembly 性能分析

下图是与典型网页应用相比时，WebAssembly 的大体过程。

不一样浏览器的处理可能略有不一样，下面咱们以 SpiderMonkey 引擎为例来讲明各个过程。

加载

加载这部分并无体如今上图中，但这部分所耗费的时间就是从服务器下载文件的时间。

由于 WebAssembly 代码比 JavaScript 代码更加的精简，因此加载 WebAssembly 文件是更快的。
尽管压缩算法可以极大减少 JavaScript 代码的体积，可是 WebAssembly 压缩后的二进制代码仍然比它要小。

这就意味着下载将耗费更少时间，尤为是在低网速状况下。

解析

JavaScript 代码一旦下载到浏览器，它会被解析为抽象语法树（AST）。

浏览器一般采用的策略是惰性处理，即只解析真正被用到的代码以及只为还没被调用的函数建立存根。

以后，AST 被转化为引擎相关的中间代码：字节码（Bytecode）。

而 WebAssembly 则不须要这种转换，由于它自己已是一种中间代码了。它只须要通过解码，而且验证解码没有发生错误便可。

编译+优化

正如前面关于 JIT 的文章所说，JavaScript 的编译时发生在代码运行期间的。根据运行时所用的不一样数据类型，相同代码可能须要被编译为多种代码。

不一样的浏览器编译 WebAssembly 时使用不一样方式。一些浏览器会在运行代码前先进行基准编译，其余浏览器则会使用 JIT 。

但不论是哪一种方式，WebAssembly 都是从里机器码比较近的地方开始的。好比说，程序自己就包含了数据的类型信息，这样的话就会有更高的性能，由于：

• 编译器再进行优化编译以前不须要耗费时间来检查数据类型
• 编译器并不须要基于不一样类型来编译出相同代码的不一样类型版本代码
• 有不少优化已经在 LLVM 以前完成了，因此这里能够减小编译和优化的开销

从新优化

有时候 JIT 必须丢弃以前已经优化的代码而且从新编译。

这种状况就发生在 JIT 以前的假设都不成立时。好比说，当循环中使用了与以前不同的变量类型，或者原型链上新增了一个函数。

这种去优化带来了两个性能损耗。一是，JIT 须要丢弃已编译的代码并回退到基准代码；二是，若是这段代码仍然会被调用不少次，那么又得从新花费时间去再次优化它。

而在 WebAssembly 中，数据类型是很明确的，因此 JIT 不须要对运行时的数据类型作任何假设。也就意味着，它不不存在从新优化可能。

运行

编写出高性能的 JavaScript 代码是可能的。为此，你须要知道 JIT 是如何作优化的。
好比，你须要知道如何写出让编译器特定化数据类型的代码。

可是，大多数开发者并不知道 JIT 的内部实现。即使是了解 JIT 内部实现的人，也很难直接击中要害。
许多咱们为了让代码更具可读性的编程模式（好比抽出公共函数来处理多种类型）反而阻碍了编译器的优化。

并且，不一样浏览器的 JIT 所采用的各类优化手段是不一样的，这就致使了可能在某款浏览器上是最优的，可是在另外一款浏览器中则是不好的。

正由于这个，运行 WebAssembly 一般是更加快速的。许多 JIT 作的优化在 WebAssembly 中根本不存在。

此外，WebAssembly 是被设计为一个编译目标的。也就是说，它是被用来做为编译器输出的，而不是用来供开发者编码的。

由于开发者不须要直接对 WebAssembly 编码，因此它可以使用更适合机器的指令，而这些指令一般能作到 10% ~ 800% 的性能提高。

垃圾回收

在 JavaScript 中，开发者并不须要专门去清理那些再也不使用的变量所占用的内存。这种清理工做由 JavaScript 引擎自动进行，称为垃圾回收（Garbage Collection）。

可是，若是你想要获得可预期的性能，这可能会成为阻碍。
你并不能控制何时进行垃圾回收，因此它随时可能发生。尽管大多数浏览器在垃圾回收的调度方面作的至关不错，可是它仍然可能阻碍你的代码运行。

至少如今，WebAssembly 根本不支持垃圾回收。全部内存都是手动管理的。
虽然这样会让编码变得更加困难，可是它也让性能变得更加稳定。

结论

因此，WebAssembly 之因此比 JavaScript 拥有更好的性能，是由于如下缘由：

• 更精简的体积让加载 WebAssembly 耗费更少时间
• 解码 WebAssembly 比解析 JavaScript 更快
• 编译和优化节省了时间开销，由于 WebAssembly 比 JavaScript 更接近机器码，并且 WebAssembly 是已经提早作过优化的
• 不会发生从新优化的过程，由于 WebAssembly 自带数据类型和其余信息
• 代码的运行耗费更好时间，由于它没有那么多编译器陷阱，并且它的指令集对机器更友好
• 不存在垃圾回收的过程，由于它是手动管理内存的

以上就是为何在大多数时候，WebAssembly 都比 JavaScript 性能好的缘由。

固然，WebAssembly 也存在表现并不如指望的那样好的时候。同时，也有一些正在进行的改变使得它变得更快。这些咱们会在下一篇中讨论。