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 系列 一 ~ 六