WebAssembly 系列

本文做者：Lin Clarkhtml

英文原文：A cartoon intro to WebAssembly前端

1 生动形象地介绍 WebAssembly

你可能已经据说过，WebAssembly 执行的更快。可是 WebAssembly 为何执行的更快呢？webpack

在这个系列文章中，我会为你解释这一点。git

1.1 什么是 WebAssembly？

WebAssembly 是除了 JavaScript 之外，另外一种能够在浏览器中执行的编程语言。因此当人们说 WebAssembly 更快的时候，通常来说是与 JavaScript 相比而言的。github

这里并非暗示你们说开发时只能选择 WebAssembly或 JavaScript。实际上，咱们更但愿在同一个工程中，两个你同时使用。web

对两者的比较却是很是有必要的，这样你就能够了解到 WebAssembly 所拥有的独特特性。算法

1.2 一些关于性能的历史

JavaScript 于 1995 年问世，它的设计初衷并非为了执行起来快，在前 10 个年头，它的执行速度也确实不快。npm

紧接着，浏览器市场竞争开始激烈起来。编程

被人们广为传播的“性能大战”在 2008 年打响。许多浏览器引入了 Just-in-time 编译器，也叫 JIT。基于 JIT 的模式，JavaScript 代码的运行渐渐变快。后端

正是因为这些 JIT 的引入，使得 JavaScript 的性能达到了一个转折点，JS 代码执行速度快了 10 倍。

随着性能的提高，JavaScript 能够应用到之前根本没有想到过的领域，好比用于后端开发的 Node.js。性能的提高使得 JavaScript 的应用范围获得很大的扩展。

如今经过 WebAssembly，咱们颇有可能正处于第二个拐点。

2 JavaScript Just-in-time (JIT) 工做原理

英文原文: A crash course in just-in-time (JIT) compilers

JavaScript 刚出现时的运行速度是很慢的，多亏了 JIT，它的运行速度变得快了起来。JIT 是如何工做的呢？

2.1 JavaScript 是如何在浏览器中运行的

当开发者将 JavaScript 添加到页面当中，既有必定的目的也会遇到必定的困难。

目标: 告诉电脑要作什么

困难: 计算机和人类说着不一样的语言

你说着人类的语言，而计算机使用的则是机器语言。就算你把或者其余的高级编程语言看做是人类的语言，它们也确实是。这些语言设计的初衷是方便人类识别，而不是方便计算机识别。

因此引擎的做用即是将人类语言转化成机器所能理解的东西。

我把这个过程想象成电影《[降临](https://en.wikipedia.org/wiki/Arrival_(film)》中的场景 —— 人类和外星人尝试着互相沟通。

在那部电影里，人类和外星人并非纯粹地文字对文字地翻译。这两个种族对世界有着不同的思考方式。对于人类和计算机来讲也是同样的。 (我会在下一篇文章中作更多的解释)。

因此人类和计算机的沟通是如何翻译的呢？

在编程中，有两种方式转换成机器语言——使用解释器或者编译器。

使用解释器，这个翻译几乎是一行紧接着接着一行的。

另外一方面，编译器是不会逐行翻译的。它会在运行前提起翻译而且记录下来。

这两种翻译方式各有其利弊。

解释器的利与弊

解释器很快就能准备好而且运行。在运行代码以前，解释器没必要将整个编译过程都进行完。它在翻译完第一行时就开始执行。

正由于如此，编译器和 JavaScript 就好像一拍即合。对于 web 开发者来讲，让他们可以快速的运行他们的代码这点是很是重要的。

这就是为何浏览器在一开始使用 JavaScript 解释器。

可是在你屡次使用解释器解释运行相同的代码时，它的弊端就出现了。好比，使用循环。它老是会反复地去翻译相同的东西。

编译器的利与弊

编译器对此有着相反的权衡。

它启动须要更多的时间，由于它必须在开始时就完成整个编译阶段。可是循环里的代码会运行地更快，由于它不须要去每次重复地翻译那个循环。

另一个不一样的地方是编译器会花一些时间对代码作出编辑，让代码可以更快地运行。这些编辑的行为被称之为优化。

解释器是在运行时工做的，因此它没法在翻译阶段花费不少时间去优化。

2.2 即时编译器：一箭双鵰

为了摆脱解释器的重复翻译的低效行为，浏览器开始将编译器混入其中。

不一样的浏览器有着不一样的实现，可是基本思想都是同样的。他们会给 They added a new part to the JavaScript 引擎添加一个新的部分叫作监视器（也称之为分析器）。监视器会观察这些代码的运行，而后记录这些代码运行的次数以及他们使用的类型。

一开始，监视器会观察全部通过解释器的东西。

若是其中一行代码运行了几回，这段代码称之为温和的，若是它运行了不少次，那么它被称之为激烈的。

基线编译器

当一个函数开始变得温和起来，JIT 会将它发送至编译器，而后将编译结果储存下来。

这个函数的每一行都会被编译到 “存根” 里。这些存根根据行号和变量类型来编入索引。(稍后我会解释这一点的重要性)。若是监视器发现有着一样变量类型的同一段代码被重复执行了，那么它会将已经编译好的版本直接提取出来。

这有助于代码的快速运行。可是正如我所说的，编译器还可以作更多的事情。它会花费一些时间来找出最有效的运行方式，从而达到优化。

基线编译器会进行一些优化（我会在下面给出一些例子）。这个过程不会花费不少时间，由于它不会将代码的执行时间拖得过久。

而后，若是代码被执行的频率很高，执行花费的时间不少，那么花费一些额外的时间来对它进行优化是很是值得的。

优化编译器

当一部分代码出现的频率很是高时，监视器会将它们发送至优化编译器。这会建立一个更快的版本，并存储起来。

为了建立出一个更快的版本，优化编译器必须作出一些假设。

打个比方，若是它能假设全部经过某个特定的构造器建立出来的对象都拥有一样的结构，也就是说，他们老是拥有相同的属性名，属性被添加的顺序也相同，那么它就可以走捷径。

优化编译器会使用监视器观察代码执行收集到的信息来作出决定。若是在以前全部的循环中的条件都为真，它会假设循环条件会继续为真。

不过对于 JavaScript 来讲，没有什么是绝对的。你可能会有99个具备相同结构的对象，而后第100个对象可能就少了个属性。

因此被编译的代码须要在执行以前检查，肯定以前编译器的猜想是不是正确的。若是是，那么这些代码就能够直接运行，反之，JIT 会假定它作了错误的猜想并将这些优化过的代码销毁。

而后执行又将回到解释器或者基线编译的版本。这个过程叫作去优化（或者是摆脱）。

一般来讲，优化编译器会让代码可以更快地运行。可是有时候它们也会致使一些预料以外的性能问题。若是一段代码反复地处于优化和去优化的过程，那么最后它反而会比直接执行基线编译版原本得更慢。

大多数浏览器会限制优化/去优化循环的次数。好比说，JIT 执行了超过 10 次优化，而这 10 次优化尝试都失败了，那么它会对它中止优化。

2.3 一个优化的例子：类型特化

优化的方式有不少种，可是我想看一下其中一种类型的优化，这样你就可以感觉到优化是怎么发生的。优化编译器的最大优点之一称之为类型特化。

JavaScript 所使用的动态类型系统在运行时须要作一些额外的工做。好比，考虑如下代码：

function arraySum(arr) {
  var sum = 0;
  for (var i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
}

循环中的 += 这一步骤看起来很是简单，彷佛你均可以一步计算出来，可是由于动态类型，它可能比你预期要花费更多的步骤。

让咱们假设 arr是一个有着 100 个整数的数组。一旦代码变得“温和”，基线编译器会为函数内的每次操做都建立一个存根。全部会有对 sum += arr[i] 的存根，它掌管着对整数的 += 加法操做。

然而，sum 和 arr[i] 并不总保证是整数。由于 JavaScript 的类型是动态的，可能在以后循环中的某一步中，arr[i]变成了一个字符串。整数加法和字符拼接这两种操做有着很大的不一样，因此他们会被编译成很是不同的机器码。

JIT 处理这种状况的方式是编译多个基线存根。若是一段代码是单型的（每次都是调用一样的类型），那么它会获得一个存根。若是这段代码是多态的（一种类型经过代码调用传递到另外一种类型），那么每种类型的组合的操做产生的结果都会获得一个存根。

这意味着 JIT 在选择一个存根的时候要询问不少次。

由于每一行代码在基线编译器中都有本身的存根，JIT 在每行代码执行的时候都会去检查它的类型。因此对于循环中的每一次迭代，JIT 都会去询问相同的问题。

若是 JIT 不须要重复这些类型检查的话，那么代码的执行会变得更快。这就是优化编译器所作的事情之一。

在优化编译器当中，整个函数是一块儿编译的。类型检查被移动到循环以前以便于执行。

一些 JIT 更进一步地进行了优化。好比，在 Firefox 当中，对于只包含整数的数组有特殊的分类。若是 arr 是它们其中之一，那么 JIT 就不须要检查 arr[i] 是不是整数。这意味着 JIT 能够在进入循环以前就作完全部的类型检查。

2.4 JIT工做原理总结

以上就是对 JIT 的归纳。它经过监测运行的代码并将运行频率高的的代码拿去优化来加快 JavaScript 的运行速度。这使得大多数 JavaScrip t应用程序的性能成倍地提升。

就算有了这些提高，JavaScript 的性能也是难以预计的。为了使得运行速度更快，JIT 使用了一些过分开销，包括：

优化和去优化
用于监视器记录以及去优化发生时恢复信息所占用的内存
用于存储基线和函数优化版本的内存

这里仍然有改进的空间：移除这些过分的开销，使得性能变得更好预测。这也是 WebAssembly 所作的事情之一。

3 编译器如何生成汇编

理解 WebAssembly 是如何运行的，有助于理解什么是汇编以及编译器是如何产生汇编的。

在关于JIT的这篇文章，我谈到了为何机器沟通就像和外星人沟通同样。

我如今想看一下那个外星人的大脑是如何工做的，对于来自外界的通信，机器的大脑是如何分析和理解的。

在它的大脑中，有一部分致力于思考——像是加减法或者逻辑操做。也有相邻的一部分提供短时间记忆，而后还有另一部分提供长期记忆。

这些不一样的部分都有各自的名称。

思考的部分叫作算数逻辑单元 (ALU)。
寄存器提供了储存短时间记忆的功能。
长期记忆就是咱们所说的随机存储存储器 (RAM)。

机器码中的语句称之为指令。

当指令传递给大脑的时候，究竟发生了什么？指令会被分红几个不一样的部分，这些部分有着不一样的含义。

指令被切分的方式取决于大脑的布线。

打个比方，若是大脑是这样的布线，它极可能老是取前 6 个比特而后输送到 ALU 当中。根据 1 和 0 的位置，ALU 会计算并知道是要讲这二者相加。

这一块称做 “opcode” 也叫称做操做码，由于它告诉 ALU 要执行什么样的操做。

而后大脑会将以后的包含三个比特的两个块所表明的数字来相加。这些会决定寄存器的地址。

注意图上的机器码的注释，它有利于咱们人类理解机器内部的运做。这就是汇编。它被称为符号机器码，是人类理解机器码的一种方式。

在这里你能够发现这个机器的机器码和汇编的最直接的关系。所以，对于不一样的机器架构会有与之对应的不一样的汇编。当你的机器内部有两种不一样的架构，那么颇有可能这台机器有它本身独特的汇编方式。

因此咱们有可能面对着不止一个翻译目标。并非说仅仅只有一种叫作机器码的语言，而是存在和不少不一样的类型的机器码。就像咱们人类说着不一样的语言同样，机器也说着不一样的语言。

当将人类的语言翻译成外形人的语言的时候，你可能会将英语，或者俄语，或者是普通话翻译成对应的外星语言 A 或者外星语言 B。而在编程领域，这就像将 C 或者 C++ 或者 Rust 转换到 x86 或者是 ARM.

若是你想要将这些高级编程语言向下转译为任何的对应不一样架构的汇编语言。一种作法就是去创造一堆出不一样的转换器，将它们一对一地转换成对应的汇编。

这么作显然效率不高。为了解决这个问题，大多数的编译在他们中间放置了最少一个中间层。编译器会将高级编程语言，转换为没那么高的级别，固然它也没法在机器代码这样的级别上运行。这称做中介表示 (IR)。

这意味着编译器能够将任何一种高级语言转换成 IR 语言。至此，编译器的另一部分就能够将 IR 向下编译成特定的目标结构的代码。

编译器的前端将高级程序语言转换成 IR。编译器的后端将 IR 转换成特定目标结构的汇编码。

4 WebAssembly 工做原理

WebAssembly 是一种在页面中运行除了之外的编程语言的方法。在过去，若是你想要使你的代码能在浏览器中运行而且和浏览器交互，JavaScript 是你惟一的选择。

因此当人们谈论到 WebAssembly 的运行之快时，对于 JavaScript，比如谈论的是是苹果和苹果之间的较量。可是这并不意味着你只能在 WebAssembly 与 JavaScript 之间二选一。

事实上，咱们指望开发者可以在开发同一个应用时结合两种技术。就算你本身不写 WebAssembly，你也能够利用它的优点。

WebAssembly 模块定义的函数能够被 JavaScript 所用。就比如，你从 npm 下载了一个诸如 lodash 这样的模块而后调用了它提供的 API 。在未来你也能够下载 WebAssembly 的模块。

如今，就让咱们来看怎样去建立 WebAssembly 模块并在 JavaScript 中使用这些它们。

4.1 WebAssembly 要安放在哪呢？

在这篇关于汇编的文章里，我谈论了编译器是如何将高级编程语言转换为机器码的。

对于上图，WebAssembly 要如何融入这个过程当中呢？

你可能会认为它不过就是另外一个目标汇编语言。也确实是这样，除了每一种语言（x86, ARM）都对应着不一样的机器架构。

当你的代码经过互联网传输到用户的机器上执行的时候，你并不知道你的代码要在什么样的机器上执行。

所以 WebAssembly 和其余的汇编有些不一样。它是一种概念中的机器的机器语言，而不是实际的机器的机器语言。

出于这个缘由，WebAssembly 的指令有时也称做虚拟指令。这些指令比 JavaScript 源码更加直接地映射到机器码。它们表明了某种交集，能够更加有效地跨越不一样的流行硬件。可是它们也并非直接地映射到特定的硬件的特定机器码。

浏览器下载完 WebAssembly，而后从 WebAssembly 跳转至目标机器的汇编代码。

4.2 编译至 .wasm 文件

目前对 WebAssembly 支持最好的编译工具链叫作LLVM。不一样的前端和后端能够插入到 LLVM 当中。

注: 大多数的 WebAssembly 模块大可能是开发者使用像 C 和 Rust 这样的语言编写的而后编译成WebAssembly。可是也有其余的办法能够建立 WebAssembly 模块。好比，这里一个实验性的工具可让你使用TypeScript来建立 WebAssembly 模块。或者你也能够直接使用 WebAssembly 的文本表示来编码。

假设咱们想要使 C 转换成 WebAssembly。咱们可使用 clang 前端（并不是传统意义上的前端）将 C 转换为 LLVM 中间表示(IR)。一旦它到 LLVM 的中间表示，LLVM 就能理解它而且执行一些优化操做。

为了从 LLVM’s IR (intermediate representation) 转换到 WebAssembly，咱们须要一个后端（并不是传统意义上的后端）。目前 LLVM 中有个一个正在开发中的后端。这个后端将会是主要的解决方案，而且很快就会敲定了。不过，目前使用它仍是很困难。

另一个叫作 Emscripten 的工具目前来讲较为简单一些。它有本身的后端来产生将前端语言先编译成另一种目标（叫作 asm.js）而后再将这个目标转化成 WebAssembly。它底层使用了 LLVM，所以，你能够在 Emscripten 中切换两种后端。

Emscripten 包含不少额外的工具和库，容许移植整个 C/C++ 代码库。因此它更像是一个 SDK 而不是编译器。好比，系统开发者习惯于有个能够读写的文件系统，所以， Emscripten 能够用 IndexedDB 来模拟这个系统。

不管你使用什么工具链，最后都会生成 .wasm 文件。接下来我会解释 .wasm 文件的结构。不过首先咱们先来看看怎么在 JS 中使用它。

4.3 在 JavaScript 中加载 .wasm 模块

.wasm 文件就是 WebAssembly 模块，它能够在 JavaScript 中加载。就目前而言，它的加载过程有一些复杂。

function fetchAndInstantiate(url, importObject) {
  return fetch(url).then(response =>
    response.arrayBuffer()
  ).then(bytes =>
    WebAssembly.instantiate(bytes, importObject)
  ).then(results =>
    results.instance
  );
}

想更深刻了解，请查看咱们的文档.

目前咱们正在努力使这个过程变得更加简单。咱们指望可以加强工具链而且与现有的像 webpack 或者 System.js 这样的模块打包工具整合。咱们相信将来加载模块能够像加载 modules can be as easy as as loading JavaScript 模块那样简单。

虽然目前 WebAssembly 模块和JS 模块有着一个主要的区别：WebAssembly 的函数只能使用数值 (整数或者浮点数) 做为参数或者返回值。

对于其余更复杂的数据类型，好比字符串，你必须使用 WebAssembly 模块的内存。

若是你大多数状况都在和 JavaScript 打交道，那么直接访问内存对你来讲可能不那么熟悉。更高性能的语言像 C，C++ 和 Rust，通常都有手动内存管理。WebAssembly 模块的内存模拟了堆，在这些语言中你是能够看到的。

为了达到这个目的，它使用了 JavaScript 中的 ArrayBuffer。数组缓冲就是一个全是字节的数组，数组的索引表明着具体的内存地址。

若是你想在 JavaScript 和 WebAssembly 之间传递一个字符串，你须要将字符转换成它对应的字符编码。而后将他们写进内存数组。因为索引是整数，索引就可以传递给 WebAssembly 的函数。所以，字符串中的第一个字符的索引就能够做为指针。

任何开发 WebAssembly 模块给其余 web 开发者使用的开发者极可能会对模块外面进行包装。这样，使用模块的人就没必要知道内部的内存管理的细节了。

若是你想学习更多关于这方面的知识，请查看文档中的这一部分。

4.4 .wasm 文件的结构

若是你正在使用更高级的语言书写代码并将其编译为 WebAssembly。你不须要知道 WebAssembly 模块是怎样组织结构的。可是这能够有助于理解基础知识。

若是你尚未准备好，咱们建议你先阅读关于汇编的一篇文章 (这个系列的第三部分)。

这里是一个待转换为 WebAssembly 的一个C 函数：

int add42(int num) {
  return num + 42;
}

你能够尝试使用 WASM Explorer 来编译该函数。

若是你打开 .wasm 文件 (而且你的编辑器支持其显示)，你会看到相似于如下的东西：

00 61 73 6D 0D 00 00 00 01 86 80 80 80 00 01 60
01 7F 01 7F 03 82 80 80 80 00 01 00 04 84 80 80
80 00 01 70 00 00 05 83 80 80 80 00 01 00 01 06
81 80 80 80 00 00 07 96 80 80 80 00 02 06 6D 65
6D 6F 72 79 02 00 09 5F 5A 35 61 64 64 34 32 69
00 00 0A 8D 80 80 80 00 01 87 80 80 80 00 00 20
00 41 2A 6A 0B

这是模块的“二进制”表示。这里我对二进制使用了引号是由于它一般以十六进制记数法显示，但能够很容易地转换为二进制符号，或者是人类可读的格式。

举个例子，这是 num + 42 看起来的样子。

代码是如何工做的: 堆栈机

若是你好奇的话，这里是这些指令的做用。

你或许已经注意到了， add 操做并无说它要操做的值是从哪里来的。这是由于 WebAssembly 是一种以堆栈机为模板的东西。这意味着全部操做所须要的值都在操做执行以前排列在栈上。

像 add 这样的操做知道它须要多少个值，因为add 操做须要两个值，因此它会从栈顶提取两个值。这意味着 add 指令能够变得很短（单个字节），由于这个指令不须要指定源或者目标寄存器。这样可以减少 .wasm 文件的体积，这也意味着须要更少的时间来下载它。

尽管 WebAssembly 明确按照堆栈机的规定, 可是这并非它在物理机器上工做的方式。当浏览器将 WebAssembly 翻译成浏览器所在的机器的机器码的时候，它会用到寄存器。因为Since the WebAssembly 代码并不指定寄存器，它给浏览器提供了更大的灵活性来分配最适合机器的寄存器。

模块的区块

除了 add42 函数自己，还有其余的部分在 .wasm 文件当中。这些叫作区块。有些区块是任何的模块都须要的，有些是可选的。

必需的:

Type 包含任何定义在该模块或者导入进来的函数的签名。
Function 给在该模块定义的每个函数创建一个索引。
Code 该模块的每个函数的实际函数体。

可选的:

Export 使得其余 WebAssembly 模块和 JavaScript 可使用该模块内的函数，内存，表以及全局。这容许单独编译的模块可以被动态的连接到一块儿。这就是 WebAssembly版的 .dll 。
Import 指定从其余 WebAssembly 模块和 JavaScript 引入的函数，内存，表以及全局。
Start 一个函数，在 WebAssembly 模块加载完成以后自动执行（有点像 main 函数）。
Global 声明模块的全局变量。
Memory 定义该模块将要使用的内存。
Table 使得它能够映射到的 Webassembly 模块之外的值，如JavaScript对象。这对于容许间接函数调用特别有用。
Data 初始化导入或本地内存。
Element 初始化导入或本地表。.

5 为何 WebAssembly 更快？

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

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

而开发者们选择替换为 WebAssembly 的缘由正是由于 WebAssembly 比较快。

5.1 当前的 JavaScript 性能如何？

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

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

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

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

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

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

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

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

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

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

5.2 WebAssembly 对比

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

各类浏览器处理上图中不一样的过程，有着细微的差异，拿 SpiderMonkey 做为例子。

文件获取

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

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

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

解析

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

浏览器采用懒加载的方式进行，只解析真正须要的部分，而对于浏览器暂时不须要的函数只保留它的桩（stub，译者注：关于桩的解释能够在以前的文章中有说起）。

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

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

编译和优化

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

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

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

在编译优化代码以前，它不须要提早运行代码以知道变量都是什么类型。
编译器不须要对一样的代码作不一样版本的编译。
不少优化在 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++同样）。这对于开发者来说确实增长了些开发成本，不过这也使代码的执行效率更高。

5.3 总结

WebAssembly 比 JavaScript 执行更快是由于：

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

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

可是，还有一些状况 WebAssembly 表现的会不如预期；同时 WebAssembly 的将来也会朝着使 WebAssembly 执行效率更高的方向发展。

6 WebAssembly 的如今与将来

2017 年 2 月 28 日，四个主要的浏览器一致赞成宣布 WebAssembly 的MVP 版本已经完成，它是一个浏览器能够搭载的稳定版本。

它提供了浏览器能够搭载的稳定核，这个核并无包含 WebAssembly 组织所计划的全部特征，而是提供了可使 WebAssembly 稳定运行的基本版本。

这样一来开发者就可使用 WebAssembly 代码了。对于旧版本的浏览器，开发者能够经过 asm.js 来向下兼容代码，asm.js 是 JavaScript 的一个子集，全部 JS 引擎均可以使用它。另外，经过 Emscripten 工具，你能够把你的应用编译成 WebAssembly 或者 asm.js。

尽管是第一个版本，WebAssembly 已经能发挥出它的优点了，将来经过不断地改善和融入新特征，WebAssembly 会变的更快。

6.1 提高浏览器中 WebAssembly 的性能

随着各类浏览器都使本身的引擎支持 WebAssembly，速度提高就变成天然而然的了，目前各大浏览器厂商都在积极推进这件事情。

JavaScript 和 WebAssembly 之间调用的中间函数

目前，在 JS 中调用 WebAssembly 的速度比本应达到的速度要慢。这是由于中间须要作一次“蹦床运动”。JIT 没有办法直接处理 WebAssembly，因此 JIT 要先把 WebAssembly 函数发送到懂它的地方。这一过程是引擎中比较慢的地方。

按理来说，若是 JIT 知道如何直接处理 WebAssembly 函数，那么速度会有百倍的提高。

若是你传递的是单一任务给 WebAssembly 模块，那么不用担忧这个开销，由于只有一次转换，也会比较快。可是若是是频繁地从 WebAssembly 和 JavaScript 之间切换，那么这个开销就必需要考虑了。

快速加载

JIT 必需要在快速加载和快速执行之间作权衡。若是在编译和优化阶段花了大量的时间，那么执行的必然会很快，可是启动会比较慢。目前有大量的工做正在研究，如何使预编译时间和程序真正执行时间二者平衡。

WebAssembly 不须要对变量类型作优化假设，因此引擎也不关心在运行时的变量类型。这就给效率的提高提供了更多的可能性，好比可使编译和执行这两个过程并行。

加之最新增长的 JavaScript API 容许 WebAssembly 的流编译，这就使得在字节流还在下载的时候就启动编译。

FireFox 目前正在开发两个编译器系统。一个编译器先启动，对代码进行部分优化。在代码已经开始运行时，第二个编译器会在后台对代码进行全优化，当全优化过程完毕，就会将代码替换成全优化版本继续执行。

6.2 添加后续特性到 WebAssembly 标准的过程

WebAssembly 的发展是采用小步迭代的方式，边测试边开发，而不是预先设计好一切。

这就意味着有不少功能还在襁褓之中，没有通过完全思考以及实际验证。它们想要写进标准，还要经过全部的浏览器厂商的积极参与。

这些特性叫作：将来特性。这里列出几个。

直接操做 DOM

目前 WebAssembly 没有任何方法能够与 DOM 直接交互。就是说你还不能经过好比element.innerHTML 的方法来更新节点。

想要操做 DOM，必需要经过 JS。那么你就要在 WebAssembly 中调用 JavaScript 函数（WebAssembly 模块中，既能够引入 WebAssembly 函数，也能够引入 JavaScript 函数）。

无论怎么样，都要经过 JS 来实现，这比直接访问 DOM 要慢得多，因此这是将来必定要解决的一个问题。

共享内存的并发性

提高代码执行速度的一个方法是使代码并行运行，不过有时也会拔苗助长，由于不一样的线程在同步的时候可能会花费更多的时间。

这时若是可以使不一样的线程共享内存，那就能下降这种开销。实现这一功能 WebAssembly 将会使用 JavaScript 中的 SharedArrayBuffer，而这一功能的实现将会提升程序执行的效率。

SIMD（单指令，多数据）

若是你以前了解过 WebAssembly 相关的内容，你可能会据说过 SIMD，全称是：Single Instruction, Multiple Data（单指令，多数据），这是并行化的另外一种方法。

SIMD 在处理存放大量数据的数据结构有其独特的优点。好比存放了不少不一样数据的 vector（容器），就能够用同一个指令同时对容器的不一样部分作处理。这种方法会大幅提升复杂计算的效率，好比游戏或者 VR。

这对于普通 web 应用开发者不是很重要，可是对于多媒体、游戏开发者很是关键。

异常处理

许多语言都仿照 C++ 式的异常处理，可是 WebAssembly 并无包含异常处理。

若是你用 Emscripten 编译代码，就知道它会模拟异常处理，可是这一过程很是之慢，慢到你都想用“DISABLEEXCEPTIONCATCHING” 标记把异常处理关掉。

若是异常处理加入到了 WebAssembly，那就不用采用模拟的方式了。而异常处理对于开发者来说又特别重要，因此这也是将来的一大功能点。

其余改进——使开发者开发起来更简单

一些将来特性不是针对性能的，而是使开发者开发 WebAssembly 更方便。

一流的开发者工具。目前在浏览器中调试 WebAssembly 就像调试汇编同样，不多的开发者能够手动地把本身的源代码和汇编代码对应起来。咱们在致力于开发出更加适合开发者调试源代码的工具。
垃圾回收。若是你能提早肯定变量类型，那就能够把你的代码变成 WebAssembly，例如 TypeScript 代码就能够编译成 WebAssembly。可是如今的问题是 WebAssembly 没办法处理垃圾回收的问题，WebAssembly 中的内存操做都是手动的。因此 WebAssembly 会考虑提供方便的 GC 功能，以方便开发者使用。
ES6 模块集成。目前浏览器在逐渐支持用 script 标记来加载 JavaScript 模块。一旦这一功能被完美执行，那么像 <script src=url type="module"> 这样的标记就能够运行了，这里的 url能够换成 WebAssembly 模块。

6.3 总结

WebAssembly 执行起来更快，随着浏览器逐步支持了 WebAssembly 的各类特性，WebAssembly 将会变得更快。

7 关于

Lin Clark

Lin 是 Mozilla Developer Relations 团队的一名工程师。 She 专一于 JavaScript, WebAssembly, Rust, 以及 Servo，同时也绘制一些关于编码的漫画。

Lin Clark 的更多文章

WebAssembly 系列 一 ~ 六