圖說 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 也存在表現並不如指望的那樣好的時候。同時，也有一些正在進行的改變使得它變得更快。這些咱們會在下一篇中討論。