WebAssembly做爲一門新興起的技術，在 JavaScript 圈很是的火！人們都在談論它多麼多麼快，怎樣怎樣改變 Web 開發領域，被各大巨頭所推廣，這篇文章對其作一個簡單的瞭解認識，本文非原創，參考文章見底部。html

1.什麼是WebAssembly

WebAssembly的名字帶個彙編Assembly，因此咱們從其名字上就能知道其意思是給Web使用的彙編語言，是經過Web執行低級二進制語法。前端

可是WebAssembly並非直接用匯編語言，而提供了抓換機制（LLVM IR），把高級別的語言（C，C++和Rust）編譯爲WebAssembly，以便有機會在瀏覽器中運行。主要是解決目前JS語言的效率問題，設計立足點爲快速，內存安全和開放。webpack

因此它實際上是一種運行機制，一種新的字節碼格式(.wasm)，而不是新的語言。 git

2.一些關於性能的歷史與Wasm的誕生

當人們說 WebAssembly 更快的時候，通常來說是與 JavaScript 相比而言的。github

JavaScript 於 1995 年問世，它的設計初衷並非爲了執行起來快，在前 10 個年頭，它的執行速度也確實不快。緊接着，瀏覽器市場競爭開始激烈起來。被人們廣爲傳播的「性能大戰」在 2008 年打響。許多瀏覽器引入了 Just-in-time 編譯器，也叫 JIT。基於 JIT 的模式，JavaScript 代碼的運行漸漸變快。正是因爲這些 JIT 的引入，使得 JavaScript 的性能達到了一個轉折點，JS 代碼執行速度快了 10 倍。web

隨着性能的提高，JavaScript 能夠應用到之前根本沒有想到過的領域，好比用於後端開發的 Node.js。性能的提高使得 JavaScript 的應用範圍獲得很大的擴展。算法

但這也漸漸暴露出了 JavaScript 的問題：typescript

語法太靈活致使開發大型 Web 項目困難；
性能不能知足一些場景的須要。

針對以上兩點缺陷，近年來出現了一些 JS 的代替語言，例如：npm

微軟的 TypeScript 經過爲 JS 加入靜態類型檢查來改進 JS 鬆散的語法，提高代碼健壯性；
谷歌的 Dart 則是爲瀏覽器引入新的虛擬機去直接運行 Dart 程序以提高性能；
火狐的 asm.js 則是取 JS 的子集，JS 引擎針對 asm.js 作性能優化。

以上嘗試各有優缺點，其中：編程

TypeScript 只是解決了 JS 語法鬆散的問題，最後仍是須要編譯成 JS 去運行，對性能沒有提高；
Dart 只能在 Chrome 預覽版中運行，無主流瀏覽器支持，用 Dart 開發的人很少；
asm.js 語法太簡單、有很大限制，開發效率低。

三大瀏覽器巨頭分別提出了本身的解決方案，互不兼容，這違背了 Web 的宗旨；是技術的規範統一讓 Web 走到了今天，所以造成一套新的規範去解決 JS 所面臨的問題迫在眉睫。

因而 WebAssembly 誕生了，WebAssembly 是一種新的字節碼格式，主流瀏覽器都已經支持 WebAssembly。和 JS 須要解釋執行不一樣的是，WebAssembly 字節碼和底層機器碼很類似可快速裝載運行，所以性能相對於 JS 解釋執行大大提高。也就是說 WebAssembly 並非一門編程語言，而是一份字節碼標準，須要用高級編程語言編譯出字節碼放到 WebAssembly 虛擬機中才能運行，瀏覽器廠商須要作的就是根據 WebAssembly 規範實現虛擬機。

在咱們沒有搞清楚 JavaScript 和 WebAssembly 之間的性能差前，咱們須要理解 JS 引擎所作的工做。

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

JavaScript 在瀏覽器中是如何運行的？

做爲一個開發人員，您將JavaScript添加到頁面時，您有一個目標並遇到一個問題。

目標：你想要告訴計算機作什麼

問題：你和計算機使用不通的語言。

您說的是人類的語言，計算機說的是機器語言。儘管你不認爲 JavaScript 或者其餘高級語言是人類語言，但事實就是這樣的。它們的設計是爲了讓人們認知，不是爲機器設計的。

因此JavaScript引擎的工做就是把你的人類語言轉化成機器所理解的語言。

這就像電影《降臨》中，人類和外星人的互相交流同樣。

在這部電影中，人類語言不能逐字翻譯成外星語言。他們的語言反映出兩種對世界不一樣的認知。人類和機器也是這樣。

因此，怎麼進行翻譯呢？

在編程中，一般有兩種翻譯方法將代碼翻譯成機器語言。你可使用解釋器或者編譯器。

使用解釋器，翻譯的過程基本上是一行一行及時生效的。

編譯器是另一種工做方式，它在執行前翻譯。

每種翻譯方法都有利弊。

3.1 解釋器的利弊

解釋器很快的獲取代碼而且執行。您不須要在您能夠執行代碼的時候知道所有的編譯步驟。所以，解釋器感受與 JavaScript 有着天然的契合。web 開發者可以當即獲得反饋很重要。

這也是瀏覽器最開始使用 JavaScript 解釋器的緣由之一。

可是實用解釋器的弊端是當你運行相同的代碼的時候。好比，你執行了一個循環。而後你就會一遍又一遍的作一樣的事情。

3.2 編譯器的利弊

編譯器則有相反的效果。在程序開始的時候，它可能須要稍微多一點的時間來了解整個編譯的步驟。可是當運行一個循環的時候他會更快，由於他不須要重複的去翻譯每一次循環裏的代碼。

由於解釋器必須在每次循環訪問時不斷從新轉換代碼，做爲一個能夠擺脫解釋器低效率的方法，瀏覽器開始將編譯器引入。

不一樣的瀏覽器實現起來稍有不一樣，可是基本目的是相同的。他們給 JavaScript 引擎添加了一個新的部分，稱爲監視器（也稱爲分析器）。該監視器在 JavaScript 運行時監控代碼，並記錄代碼片斷運行的次數以及使用了那些數據類型。

若是相同的代碼行運行了幾回，這段代碼被標記爲「warm」。若是運行次數比較多，就被標記爲「hot」。

被標記爲「warm」的代碼被扔給基礎編譯器，只能提高一點點的速度。被標記爲「hot」的代碼被扔給優化編譯器，速度提高的更多。

關於解釋器編譯器，能夠讀原文 https://blog.csdn.net/chenqiuge1984/article/details/80128715

4. 編譯器如何生成彙編

理解什麼是彙編，以及編譯器如何生成它，對於理解 WebAssembly 是頗有幫助的。

上面說到，人和計算機打交道，就像同外星人打交道同樣。

如今來思考一下「外星人」的大腦是如何工做的——機器的「大腦」是如何對咱們輸入給它的內容進行分析和理解的。

「大腦」中，有一部分負責思考——處理加法、減法或者邏輯運算。還有其餘的部分分別負責短暫記憶和長期記憶的。

這些不一樣的部分都有本身的名字：

負責思考的部分叫作算數邏輯單元（ALU）；

寄存器提供短暫記憶功能；

隨機存取存儲器（RAM）提供長期記憶功能。

機器代碼中的語句稱做指令。

那麼在指令進入「大腦」之後都發生了什麼呢？它們會被切分爲不一樣的部分傳送到不一樣的單元進行處理。

「大腦」切分指令經過不一樣鏈接線路進行。舉個例子，「大腦」會將指令最開始的 6 比特經過管道送到 ALU 中。而 ALU 會經過 0 和 1 的位置來決定對兩個數作加法。

這串 01 串就叫作「操做碼」，它告訴了 ALU 要執行什麼樣的操做。

而後「大腦」會取後面兩個連續的 3 比特 01 串來肯定把哪兩個數加到一塊兒，而這 3 比特指的是寄存器的地址。

注意看上面機器碼的註釋：「ADD R1 R2」，這對於人類來說很容易理解其含義。這就是彙編，也叫符號機器碼，它令人類也能看懂機器代碼的含義。

能夠看到彙編和這臺機器的機器碼之間有直接的映射關係。正是由於如此，擁有不一樣機器結構的計算機會有不一樣的彙編系統。若是你有一個機器，它有本身的內部結構，那麼它就須要它所獨有的彙編語言。

從上面的分析能夠知道咱們進行機器碼的翻譯並非只有一種，不一樣的機器有不一樣的機器碼，就像咱們人類也說各類各樣的語言同樣，機器也「說」不一樣的語言。

人類和外星人之間的語言翻譯，可能會從英語、德語或中文翻譯到外星語 A 或者外星語 B。而在程序的世界裏，則是從 C、C++ 或者 JAVA 翻譯到 x86 或者 ARM。

你想要從任意一個高級語言翻譯到衆多彙編語言中的一種（依賴機器內部結構），其中一種方式是建立不一樣的翻譯器來完成各類高級語言到彙編的映射。

這種翻譯的效率實在過低了。爲了解決這個問題，大多數編譯器都會在中間多加一層。它會把高級語言翻譯到一個低層，而這個低層又沒有低到機器碼這個層級。這就是中間代碼（ intermediate representation，IR）。

這就是說編譯器會把高級語言翻譯到 IR 語言，而編譯器另外的部分再把 IR 語言編譯成特定目標結構的可執行代碼。

從新總結一下：編譯器的前端把高級語言翻譯到 IR，編譯器的後端把 IR 翻譯成目標機器的彙編代碼。

5.WebAssembly 的工做原理。

WebAssembly 是除了 JavaScript 之外，另外一種能夠在網頁中運行的編程語言。過去若是你想在瀏覽器中運行代碼來對網頁中各類元素進行控制，只有 JavaScript 這一種選擇。

因此當人們談論 WebAssembly 的時候，每每會拿 JavaScript 來進行比較。可是它們其實並非「二選一」的關係——並非只能用 WebAssembly 或者 JavaScript。

實際上，咱們鼓勵開發者將這兩種語言一塊兒使用，即便你不親自實現 WebAssembly 模塊，你也能夠學習它現有的模塊，並它的優點來實現你的功能。

WebAssembly 模塊定義的一些功能能夠經過 JavaScript 來調用。因此就像你經過 npm 下載 lodash 模塊並經過 API 使用它同樣，將來你也能夠下載 WebAssembly 模塊而且使用其提供的功能。

那麼就讓咱們來看一下如何開發 WebAssembly 模塊，以及如何經過 JavaScript 使用他們。

5.1 WebAssembly 處於哪一個環節？

上面說到編譯器是如何從高級語言翻譯到機器碼的。

那麼在上圖中，WebAssembly 在什麼位置呢？實際上，你能夠把它當作另外一種「目標彙編語言」。

每一種目標彙編語言（x8六、ARM）都依賴於特定的機器結構。當你想要把你的代碼放到用戶的機器上執行的時候，你並不知道目標機器結構是什麼樣的。

而 WebAssembly 與其餘的彙編語言不同，它不依賴於具體的物理機器。能夠抽象地理解成它是概念機器的機器語言，而不是實際的物理機器的機器語言。

正由於如此，WebAssembly 指令有時也被稱爲虛擬指令。它比 JavaScript 代碼更直接地映射到機器碼，它也表明了「如何能在通用的硬件上更有效地執行代碼」的一種理念。因此它並不直接映射成特定硬件的機器碼。

瀏覽器把 WebAssembly 下載下來後，能夠迅速地將其轉換成機器彙編代碼。

5.2 編譯到 .wasm 文件

目前對於 WebAssembly 支持狀況最好的編譯器工具鏈是 LLVM。有不少不一樣的前端和後端插件能夠用在 LLVM 上。

提示：不少 WebAssembly 開發者用 C 語言或者 Rust 開發，再編譯成 WebAssembly。其實還有其餘的方式來開發 WebAssembly 模塊。例如利用 TypeScript 開發 WebAssembly 模塊，或者直接用文本格式的 WebAssembly 也能夠。

假設想從 C 語言到 WebAssembly，咱們就須要 clang 前端來把 C 代碼變成 LLVM 中間代碼。當變換成了 LLVM IR 時，說明 LLVM 已經理解了代碼，它會對代碼自動地作一些優化。

爲了從 LLVM IR生成 WebAssembly，還須要後端編譯器。在 LLVM 的工程中有正在開發中的後端，並且應該很快就開發完成了，如今這個時間節點，暫時還看不到它是如何起做用的。

還有一個易用的工具，叫作 Emscripten。它經過本身的後端先把代碼轉換成本身的中間代碼（叫作 asm.js），而後再轉化成 WebAssembly。實際上它背後也是使用的 LLVM。

Emscripten 還包含了許多額外的工具和庫來包容整個 C/C++ 代碼庫，因此它更像是一個軟件開發者工具包（SDK）而不是編譯器。例如系統開發者須要文件系統以對文件進行讀寫，Emscripten 就有一個 IndexedDB 來模擬文件系統。

關於工具鏈，可移步另外一篇文章Windows10下WebAssembly C/C++編譯環境的搭建與Hello World嘗試，只要知道最終生成了 .wasm 文件就能夠了。後面我會介紹 .wasm 文件的結構，在這以前先一塊兒瞭解一下在 JS 中如何使用它。

5.3 加載一個 .wasm 模塊到 JavaScript

.wasm 文件是 WebAssembly 模塊，它能夠加載到 JavaScript 中使用，現階段加載的過程稍微有點複雜。

1 function fetchAndInstantiate(url, importObject) { 2   return fetch(url).then(response =>
3  response.arrayBuffer() 4   ).then(bytes =>
5  WebAssembly.instantiate(bytes, importObject) 6   ).then(results =>
7  results.instance 8  ); 9 }

若是想深刻了解，能夠在 MDN 文檔中瞭解更多。

咱們一直在致力於把這一過程變得簡單，對工具鏈進行優化。但願可以把它整合到現有的模塊打包工具中，好比 webpack 中，或者整合到加載器中，好比 SystemJS 中。咱們相信加載 WebAssembly 模塊也能夠像加載 JavaScript 同樣簡單。

這裏介紹 WebAssembly 模塊和 JavaScript 模塊的主要區別。當前的 WebAssembly 只能使用數字（整型或者浮點型）做爲參數或者返回值。

對於任何其餘的複雜類型，好比 string，就必須得用 WebAssembly 模塊的內存操做了。若是是常用 JavaScript，對直接操做內存不是很熟悉的話，能夠回想一下 C、C++ 和 Rust 這些語言，它們都是手動操做內存。WebAssembly 的內存操做和這些語言的內存操做很像。

爲了實現這個功能，它使用了 JavaScript 中稱爲 ArrayBuffer 的數據結構。ArrayBuffer 是一個字節數組，因此它的索引（index）就至關於內存地址了。

若是你想在 JavaScript 和 WebAssembly 之間傳遞字符串，能夠利用 ArrayBuffer 將其寫入內存中，這時候 ArrayBuffer 的索引就是整型了，能夠把它傳遞給 WebAssembly 函數。此時，第一個字符的索引就能夠當作指針來使用。

這就好像一個 web 開發者在開發 WebAssembly 模塊時，把這個模塊包裝了一層外衣。這樣其餘使用者在使用這個模塊的時候，就不用關心內存管理的細節。

若是你想了解更多的內存管理，看一下咱們寫的 WebAssembly 的內存操做。

5.4 .wasm 文件結構

若是你是寫高級語言的開發者，而且經過編譯器編譯成 WebAssembly，那你不用關心 WebAssembly 模塊的結構。可是瞭解它的結構有助於你理解一些基本問題。

這段代碼是即將生成 WebAssembly 的 C 代碼：

1 int add42(int num) { 2     return num + 42; 3 }

你可使用 WASM Explorer 來編譯這個函數。

打開 .wasm 文件（假設你的編輯器支持的話），能夠看到下面代碼：

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

這是模塊的「二進制」表示。之因此用引號把「二進制」引發來，是由於上面實際上是用十六進制表示的，不過把它變成二進制或者人們能看懂的十進制表示也很容易。

例如，下面是 num + 42 的各類表示方法。

5.5 代碼是如何工做的：基於棧的虛擬機

若是你對具體的操做過程很好奇，那麼這幅圖能夠告訴你指令都作了什麼。

從圖中咱們能夠注意到加操做並無指定哪兩個數字進行加。這是由於 WebAssembly 是採用「基於棧的虛擬機」的機制。即一個操做符所須要的全部值，在操做進行以前都已經存放在堆棧中。

全部的操做符，好比加法，都知道本身須要多少個值。加須要兩個值，因此它從堆棧頂部取兩個值就能夠了。那麼加指令就能夠變的更短（單字節），由於指令不須要指定源寄存器和目的寄存器。這也使得 .wasm 文件變得更小，進而使得加載 .wasm 文件更快。

儘管 WebAssembly 使用基於棧的虛擬機，可是並非說在實際的物理機器上它就是這麼生效的。當瀏覽器翻譯 WebAssembly 到機器碼時，瀏覽器會使用寄存器，而 WebAssembly 代碼並不指定用哪些寄存器，這樣作的好處是給瀏覽器最大的自由度，讓其本身來進行寄存器的最佳分配。

5.6 WebAssembly 模塊的組成部分

除了上面介紹的，.wasm 文件還有其餘部分。一些組成部分對於模塊來說是必須的，一些是可選的。

必須部分：

Type。在模塊中定義的函數的函數聲明和全部引入函數的函數聲明。
Function。給出模塊中每一個函數一個索引。
Code。模塊中每一個函數的實際函數體。

可選部分：

Export。使函數、內存、表（tables）、全局變量等對其餘 WebAssembly 或 JavaScript 可見，容許動態連接一些分開編譯的組件，即 .dll 的WebAssembly 版本。
Import。容許從其餘 WebAssembly 或者 JavaScript 中導入指定的函數、內存、表或者全局變量。
Start。當 WebAssembly 模塊加載進來的時候，能夠自動運行的函數（相似於 main 函數）。
Global。聲明模塊的全局變量。
Memory。定義模塊用到的內存。
Table。使得能夠映射到 WebAssembly 模塊之外的值，如映射到 JavaScript 的對象。這在間接函數調用時頗有用。
Data。初始化導入的或者局部內存。
Element。初始化導入的或者局部的表。

若是你想了解關於這些組成部分的更深刻的內容，能夠閱讀這些組成部分的工做原理。

6 爲何 WebAssembly 更快？

在咱們瞭解 JavaScript 和 WebAssembly 的性能區別以前，須要先理解 JS 引擎的工做原理。

這張圖大體給出瞭如今一個程序的啓動性能，目前 JIT 編譯器在瀏覽器中很常見。

JS 引擎在圖中各個部分所花的時間取決於頁面所用的 JavaScript 代碼。圖表中的比例並不表明真實狀況下的確切比例狀況。

圖中的每個顏色條都表明了不一樣的任務：

Parsing——表示把源代碼變成解釋器能夠運行的代碼所花的時間；
Compiling + optimizing——表示基線編譯器和優化編譯器花的時間。一些優化編譯器的工做並不在主線程運行，不包含在這裏。
Re-optimizing——當 JIT 發現優化假設錯誤，丟棄優化代碼所花的時間。包括重優化的時間、拋棄並返回到基線編譯器的時間。
Execution——執行代碼的時間。
Garbage collection——垃圾回收，清理內存的時間。

這裏注意：這些任務並非離散執行的，或者按固定順序依次執行的。而是交叉執行，好比正在進行解析過程時，其餘一些代碼正在運行，而另外一些正在編譯。

這樣的交叉執行給早期 JavaScript 帶來了很大的效率提高，早期的 JavaScript 執行相似於下圖，各個過程順序進行：

早期時，JavaScript 只有解釋器，執行起來很是慢。當引入了 JIT 後，大大提高了執行效率，縮短了執行時間。

JIT 所付出的開銷是對代碼的監視和編譯時間。JavaScript 開發者能夠像之前那樣開發 JavaScript 程序，而一樣的程序，解析和編譯的時間也大大縮短。這就使得開發者們更加傾向於開發更復雜的 JavaScript 應用。

同時，這也說明了執行效率上還有很大的提高空間。

6.1 WebAssembly 對比

下面是 WebAssembly 和典型的 web 應用的近似對比圖：

各類瀏覽器處理上圖中不一樣的過程，有着細微的差異，拿 SpiderMonkey 做爲例子。

6.2 文件獲取

這一步並無顯示在圖表中，可是這看似簡單地從服務器獲取文件這個步驟，卻會花費很長時間。

WebAssembly 比 JavaScript 的壓縮率更高，因此文件獲取也更快。即使經過壓縮算法能夠顯著地減少 JavaScript 的包大小，可是壓縮後的 WebAssembly 的二進制代碼依然更小。

這就是說在服務器和客戶端之間傳輸文件更快，尤爲在網絡很差的狀況下。

6.3 解析

當到達瀏覽器時，JavaScript 源代碼就被解析成了抽象語法樹。

瀏覽器採用懶加載的方式進行，只解析真正須要的部分，而對於瀏覽器暫時不須要的函數只保留它的樁（stub，譯者注：關於樁的解釋能夠在以前的文章中有說起）。

解析事後 AST （抽象語法樹）就變成了中間代碼（叫作字節碼），提供給 JS 引擎編譯。

而 WebAssembly 則不須要這種轉換，由於它自己就是中間代碼。它要作的只是解碼而且檢查確認代碼沒有錯誤就能夠了。

6.4 編譯和優化

在關於 JIT 的文章中，我有介紹過，JavaScript 是在代碼的執行階段編譯的。由於它是弱類型語言，當變量類型發生變化時，一樣的代碼會被編譯成不一樣版本。

不一樣瀏覽器處理 WebAssembly 的編譯過程也不一樣，有些瀏覽器只對 WebAssembly 作基線編譯，而另外一些瀏覽器用 JIT 來編譯。

不論哪一種方式，WebAssembly 都更貼近機器碼，因此它更快，使它更快的緣由有幾個：

在編譯優化代碼以前，它不須要提早運行代碼以知道變量都是什麼類型。
編譯器不須要對一樣的代碼作不一樣版本的編譯。
不少優化在 LLVM 階段就已經作完了，因此在編譯和優化的時候沒有太多的優化須要作。

6.5 重優化

有些狀況下，JIT 會反覆地進行「拋棄優化代碼<->重優化」過程。

當 JIT 在優化假設階段作的假設，執行階段發現是不正確的時候，就會發生這種狀況。好比當循環中發現本次循環所使用的變量類型和上次循環的類型不同，或者原型鏈中插入了新的函數，都會使 JIT 拋棄已優化的代碼。

反優化過程有兩部分開銷。第一，須要花時間丟掉已優化的代碼而且回到基線版本。第二，若是函數依舊頻繁被調用，JIT 可能會再次把它發送到優化編譯器，又作一次優化編譯，這是在作無用功。

在 WebAssembly 中，類型都是肯定了的，因此 JIT 不須要根據變量的類型作優化假設。也就是說 WebAssembly 沒有重優化階段。

6.6 執行

本身也能夠寫出執行效率很高的 JavaScript 代碼。你須要瞭解 JIT 的優化機制，例如你要知道什麼樣的代碼編譯器會對其進行特殊處理（JIT 文章裏面有提到過）。

然而大多數的開發者是不知道 JIT 內部的實現機制的。即便開發者知道 JIT 的內部機制，也很難寫出符合 JIT 標準的代碼，由於人們一般爲了代碼可讀性更好而使用的編碼模式，偏偏不合適編譯器對代碼的優化。

加之 JIT 會針對不一樣的瀏覽器作不一樣的優化，因此對於一個瀏覽器優化的比較好，極可能在另一個瀏覽器上執行效率就比較差。

正是由於這樣，執行 WebAssembly 一般會比較快，不少 JIT 爲 JavaScript 所作的優化在 WebAssembly 並不須要。另外，WebAssembly 就是爲了編譯器而設計的，開發人員不直接對其進行編程，這樣就使得 WebAssembly 專一於提供更加理想的指令（執行效率更高的指令）給機器就行了。

執行效率方面，不一樣的代碼功能有不一樣的效果，通常來說執行效率會提升 10% - 800%。

6.7 垃圾回收

JavaScript 中，開發者不須要手動清理內存中不用的變量。JS 引擎會自動地作這件事情，這個過程叫作垃圾回收。

但是，當你想要實現性能可控，垃圾回收可能就是個問題了。垃圾回收器會自動開始，這是不受你控制的，因此頗有可能它會在一個不合適的時機啓動。目前的大多數瀏覽器已經能給垃圾回收安排一個合理的啓動時間，不過這仍是會增長代碼執行的開銷。

目前爲止，WebAssembly 不支持垃圾回收。內存操做都是手動控制的（像 C、C++同樣）。這對於開發者來說確實增長了些開發成本，不過這也使代碼的執行效率更高。

6.8 總結

WebAssembly 比 JavaScript 執行更快是由於：

文件抓取階段，WebAssembly 比 JavaScript 抓取文件更快。即便 JavaScript 進行了壓縮，WebAssembly 文件的體積也比 JavaScript 更小；
解析階段，WebAssembly 的解碼時間比 JavaScript 的解析時間更短；
編譯和優化階段，WebAssembly 更具優點，由於 WebAssembly 的代碼更接近機器碼，而 JavaScript 要先經過服務器端進行代碼優化。
重優化階段，WebAssembly 不會發生重優化現象。而 JS 引擎的優化假設則可能會發生「拋棄優化代碼<->重優化」現象。
執行階段，WebAssembly 更快是由於開發人員不須要懂太多的編譯器技巧，而這在 JavaScript 中是須要的。WebAssembly 代碼也更適合生成機器執行效率更高的指令。
垃圾回收階段，WebAssembly 垃圾回收都是手動控制的，效率比自動回收更高。

這就是爲何在大多數狀況下，同一個任務 WebAssembly 比 JavaScript 表現更好的緣由。

可是，還有一些狀況 WebAssembly 表現的會不如預期；同時 WebAssembly 的將來也會朝着使 WebAssembly 執行效率更高的方向發展。

7.WebAssembly 的如今與將來

2017 年 2 月 28 日，四個主要的瀏覽器一致贊成宣佈 WebAssembly 的MVP 版本已經完成，它是一個瀏覽器能夠搭載的穩定版本。

它提供了瀏覽器能夠搭載的穩定核，這個核並無包含 WebAssembly 組織所計劃的全部特徵，而是提供了可使 WebAssembly 穩定運行的基本版本。

這樣一來開發者就可使用 WebAssembly 代碼了。對於舊版本的瀏覽器，開發者能夠經過 asm.js 來向下兼容代碼，asm.js 是 JavaScript 的一個子集，全部 JS 引擎均可以使用它。另外，經過 Emscripten 工具，你能夠把你的應用編譯成 WebAssembly 或者 asm.js。

儘管是第一個版本，WebAssembly 已經能發揮出它的優點了，將來經過不斷地改善和融入新特徵，WebAssembly 會變的更快。

7.1 提高瀏覽器中 WebAssembly 的性能

隨着各類瀏覽器都使本身的引擎支持 WebAssembly，速度提高就變成天然而然的了，目前各大瀏覽器廠商都在積極推進這件事情。

7.2 JavaScript 和 WebAssembly 之間調用的中間函數

目前，在 JS 中調用 WebAssembly 的速度比本應達到的速度要慢。這是由於中間須要作一次「蹦牀運動」。JIT 沒有辦法直接處理 WebAssembly，因此 JIT 要先把 WebAssembly 函數發送到懂它的地方。這一過程是引擎中比較慢的地方。

按理來說，若是 JIT 知道如何直接處理 WebAssembly 函數，那麼速度會有百倍的提高。

若是你傳遞的是單一任務給 WebAssembly 模塊，那麼不用擔憂這個開銷，由於只有一次轉換，也會比較快。可是若是是頻繁地從 WebAssembly 和 JavaScript 之間切換，那麼這個開銷就必需要考慮了。

7.3 快速加載

JIT 必需要在快速加載和快速執行之間作權衡。若是在編譯和優化階段花了大量的時間，那麼執行的必然會很快，可是啓動會比較慢。目前有大量的工做正在研究，如何使預編譯時間和程序真正執行時間二者平衡。

WebAssembly 不須要對變量類型作優化假設，因此引擎也不關心在運行時的變量類型。這就給效率的提高提供了更多的可能性，好比可使編譯和執行這兩個過程並行。

加之最新增長的 JavaScript API 容許 WebAssembly 的流編譯，這就使得在字節流還在下載的時候就啓動編譯。

FireFox 目前正在開發兩個編譯器系統。一個編譯器先啓動，對代碼進行部分優化。在代碼已經開始運行時，第二個編譯器會在後臺對代碼進行全優化，當全優化過程完畢，就會將代碼替換成全優化版本繼續執行。

7.4 添加後續特性到 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 模塊。一旦這一功能被完美執行，那麼像