[譯][A crash course in WebAssembly] 爲何WebAssembly這麼快

---

title: [A crash course in WebAssembly] 爲何WebAssembly這麼快

date: 2018-3-22 23:58:00

categories: 翻譯

tags: WebAssembly

source: 原文地址

auther: Lin Clark

---

[A crash course to WebAssembly] 爲何WebAssembly這麼快

---

這是WebAssembly系列文章的第五部分，說明了它的快速之處。若是您尚未閱讀其餘文章，咱們建議您從頭開始。

在上一篇文章中，我解釋說使用WebAssembly或JavaScript進行編程不是一種是或不是的選擇。咱們並不指望太多的開發人員會編寫完整的WebAssembly代碼庫。

因此開發人員不須要在他們的應用程序中選擇使用WebAssembly仍是JavaScript。可是，咱們但願開發人員將Web部件的JavaScript代碼部分換掉。

例如，使用React的團隊能夠將他們的調解器代碼（reconciler code，又名虛擬DOM）用WebAssembly版本替換，而使用React的人不須要作任何事情......他們的應用程序不但能夠像之前同樣工做，還可以得到使用WebAssembly的好處。

開發人員之因此喜歡React團隊的開發人員進行這種替換，是由於WebAssembly速度更快。但關鍵是什麼讓它更快？

今天的JavaScript性能如何？

在咱們理解JavaScript和WebAssembly之間的性能差別以前，咱們須要瞭解JS引擎所作的工做。

這張圖給出了一個應用程序啓動性能的粗略狀況。

JS引擎執行這些任務的時間取決於頁面使用的JavaScript。此圖並不意味着表明精確的性能數字。相反，它旨在提供一個高級模型，用於說明JS和WebAssembly中相同函數的性能會有所不一樣。

每一個格子顯示花在完成特定任務上的時間。

• Parsing - 解析 - 將源代碼處理成解釋器能夠運行的東西所需的時間。

• Compiling + optimizing - 編譯 + 優化 - 在基線編譯器和優化編譯器中花費的時間。一些優化編譯器的工做不在主線程中，因此不包含在這裏。

• Re-optimizing - 重優化(去優化 + 優化) - 當JIT的*假設(assumptions)*失敗時，JIT從新優化代碼和將優化後的代碼回退到基線代碼(baseline code)花費的格外的時間。

• Execution - 執行 - 運行代碼所需的時間。

• Garbage collection - 垃圾回收 — 畫在內存清理上的時間。

須要注意的一件重要事情是：這些任務不會以離散塊或特定順序發生。相反，它們是交錯的。一些解析將會發生，而後是一些執行，而後是一些編譯，而後是一些更多的解析，而後是更多的執行等等。

這種改進所帶來的性能是JavaScript早期的一大改進，從前的性能圖看起來更像這樣：

一開始，當它只是一個運行JavaScript的解釋器時，執行速度很慢。當JIT被引入時，它大大加快了執行時間。

JIT權衡了監視和編譯代碼的開銷。若是JavaScript開發人員一直以相同的方式編寫JavaScript，那麼解析和編譯時間將會大幅減小。但性能的提高誘使開發人員建立更大的JavaScript應用程序。

這也意味着還有改進的餘地。

WebAssembly的優點又在哪裏？

下面是WebAssembly與典型Web應用程序的性能比較示意圖。

不一樣瀏覽器之間在處理這些階段方面各有實現。我在這裏使用SpiderMonkey做爲個人模型。

Fetching

這在示意圖中沒有標示，但確實須要花費時間的一件事就是從服務器上獲取文件。

由於WebAssembly比JavaScript更緊湊，因此抓取速度更快。儘管壓縮算法能夠顯着減少JavaScript包的大小，但WebAssembly的壓縮的二進制表示仍然具備優點。

這意味着它在服務器和客戶端之間傳輸所花費的時間更少。這在慢速網絡上尤爲明顯。

Parsing

一旦它到達瀏覽器，JavaScript源代碼就會被解析爲抽象語法樹(AST)。

瀏覽器一般會惰性地執行此操做，只先解析它們真正須要的內容，而後爲還沒有調用的函數建立存根(stubs)。

在這個階段，AST被轉換爲特定於該JS引擎的中間表示(intermediate representation - IR，爲 bytecode - 字節碼)

相反，WebAssembly不須要通過這個轉換，由於它已是一個IR。它只須要解碼和驗證，以確保其中沒有錯誤。

Compiling + optimizing

正如我在關於JIT的文章中解釋的那樣，JavaScript是在執行代碼期間編譯的。根據運行時(Runtime)使用的類型，可能須要編譯相同代碼的多個版本。

不一樣的瀏覽器處理編譯WebAssembly的方式不一樣。一些瀏覽器在開始執行WebAssembly以前進行基線編譯，一些則使用JIT。

不管哪一種方式，WebAssembly從一開始就更接近機器碼。例如: 類型是程序的一部分。如下是幾個快速的緣由：

1. 編譯器沒必要花費時間運行代碼，以在開始編譯優化的代碼以前觀察正在使用的類型。

2. 編譯器沒必要根據它觀察到的不一樣類型編譯相同代碼的不一樣版本。

3. 在LLVM中已經提早作了不少的優化。所以編譯和優化工做花費的時間更少。

Reoptimizing

有時JIT必須丟棄代碼的優化版本並再次嘗試優化。

當JIT基於已運行代碼作出的假設不正確時，就會發生這種狀況。例如，當進入循環的變量與先前迭代中的變量不一樣時，或者在原型鏈中插入新函數時，就會發生去優化。

去優化有兩個成本。首先，退出優化後的代碼並返回到基準版本須要一段時間。其次，若是該函數仍被大量調用，則JIT可能決定再次向優化編譯器發送它，重複優化。

在WebAssembly中，像類型這樣的東西是顯式的，因此JIT不須要根據它在運行時收集的數據來對類型進行假設。這意味着重優化將被省略。

Executing

要編寫可以如預期執行的JavaScript代碼，你須要瞭解JIT所作的優化。例如，你須要知道怎麼樣編寫代碼，才便於編譯器優化代碼，這在JIT文章中有所描述。

可是大多數開發人員並不瞭解JIT內部。 即便對那些瞭解JIT內部的開發人員來講，也很難達到最佳狀態。 人們用來使代碼更易讀的許多編碼模式（例如將通用任務抽象爲跨類型函數的函數，範型）妨礙了編譯器優化代碼。

另外，不一樣瀏覽器之間JIT使用的優化是不一樣的，因此一樣的編碼可能在另外一個瀏覽器中表現出更低的性能。

所以，在WebAssembly中代碼的執行一般更快。 WebAssembly並不須要JIT對JavaScript進行的許多優化（例如類型專用化）。

另外，WebAssembly被設計爲編譯導向的。 這意味着它被設計爲由編譯器生成，而不是由程序員手工編寫。

因爲人類程序員不須要直接對其進行編程，所以WebAssembly能夠提供一系列對機器更爲理想的指令。根據代碼的工做類型，這些指令的運行增速從10％到800％不等。

Garbage collection

在JavaScript中，開發人員無需擔憂變量的回收處理，JS引擎經過使用稱爲垃圾回收器的東西自動執行該操做。

v8 wiki 中有提到GC的工做機制————整個世界都會爲之中止

可是，若是你想要可預測的性能，這就可能會成爲問題。你沒法控制垃圾回收器什麼時候工做，它可能會在不大方便的時候發生。大多數瀏覽器已經很好地調度它，但這依舊會阻礙代碼的執行。

WebAssembly不支持垃圾收集(至少如今)。內存是手動管理的（就像 C/C++ & Rust 這樣的語言）。雖然這可能會使開發人員的編程變得更加困難，但它也可使性能更加一致。

總結

在許多狀況下，WebAssembly比JavaScript快，由於：

• 獲取WebAssembly所需的時間較少，壓縮率相比JS也更高。

• 解碼WebAssembly比解析JavaScript花費更少的時間。

• 編譯和優化花費更少的時間，由於WebAssembly比JavaScript更接近機器碼，而且已經在服務器端進行了優化。

• 從新優化不會發生，由於WebAssembly內置了類型和其餘信息，因此JS引擎不須要像優化JavaScript時那樣推測它什麼時候能夠優化。

• 執行一般花費的時間更少，由於減小了不一樣瀏覽器的優化差別，並且WebAssembly的指令集對於機器來講更爲理想。

• 不須要GC。

這就是爲何在許多狀況下，WebAssembly在執行相同任務時性能將大大超越JavaScript。

在某些狀況下，WebAssembly的表現並不像預期的那樣好，但一樣也在某些場景中得到更高的性能。我將在下一篇文章中介紹這些內容。