摘要：現狀年月日，主流的四大瀏覽器達成了共識并宣布的最小可行產品已經完成。更快的函數調用當前，在中調用函數比想象的要慢。直接操作目前，沒有任何方式能夠操作。這就導致了部分應用可能會因此而推遲發布時間。結束現如今已經相當快速。

本文是圖說 WebAssembly 系列文章的最后一篇。如果您還未閱讀之前的文章，建議您從第一篇入手。

2017 年 2 月 28 日，主流的四大瀏覽器達成了共識并宣布 WebAssembly 的最小可行產品（MVP）已經完成。這是 WebAssembly 搭載在瀏覽器上的第一個穩定初始版本。

這也為瀏覽器提供了一個穩定的 WebAssembly 核心。雖然該核心還不好漢社區組正在計劃的所有功能，但它也確實提供了足夠的功能，使得 WebAssembly 快速且可用。

從這一刻開始，開發者也可以開始發布 WebAssembly 代碼了。對于較早版本的瀏覽器，開發者可以回退到使用 asm.js 版本的代碼。因為 asm.js 是 JavaScript 的子集，所以任何 JavaScript 引擎都可以運行它。
如果使用 Emscripten 的話，還可以把相同的應用編譯為 WebAssembly 版本和 asm.js 版本的代碼。

即使是最初的發行版本，WebAssembly 也是高性能的。但是隨著問題的修復和新功能的添加，它在未來將會擁有更高性能。

隨著瀏覽器逐步改進對 WebAssembly 的支持，性能提升也會慢慢的顯現。目前，瀏覽器廠商們正在獨自改進下面這些問題。

當前，在 JavaScript 中調用 WebAssembly 函數比想象的要慢。這是因為這個過程必須經歷一個稱為彈跳（Trampolining）的過程。JIT 并不知道如何直接處理 WebAssembly，所以它必須把 WebAssembly 轉移到知道如何處理它的地方去。這在引擎內部是一個很慢的過程，該過程會建立用來運行 WebAssembly 代碼的準備過程。

這個種處理方式可能比直接由 JIT 處理慢 100 倍。

如果將一個大型任務交給 WebAssembly 模塊來完成的話，我們可能不會注意到這種開銷。
但是如果我們在 WebAssembly 和 JavaScript 之間來回多次調用，那么這個問題就凸顯出來了。

JIT 必須在更快的加載時間和更快的運行之間做出權衡。
如果花費更多的時間在編譯和優化，雖然可以提升運行速度，但是也降低了啟動性能。

一個基本事實是，大多數的代碼的運行次數其實都還達不到需要優化的地步。
不過，目前有許多正在進行的研究，在尋找預編譯和這樣的基本事實之間的平衡點。

由于 WebAssembly 并不需要推測數據類型，所以引擎也不需要在運行時監視這些數據類型的變化。
這也就給了我們更多的選擇余地，例如把編譯和運行并行化。

此外，最近新增的 JavaScript API 允許對 WebAssembly 進行流式編譯。也就是說，引擎可以在 .wasm 還沒下載完成的時候就開始對已下載的內容進行編譯。

在 Firefox，我們正在開發雙編譯系統。一個編譯器會提前運行，并把代碼優化工作做得相當不錯。等到運行代碼的時候，另一個編譯器會在后臺進行全優化工作。一旦代碼優化完成，便會立即替換掉舊代碼。

WebAssembly 的設計目標之一是先支持小部分功能并同步進行測試，而不是從一開始就把方方面面都設計好。

因此，它還有更多功能值得期待，不過新功能還沒進行周全的考慮。只有所有瀏覽器廠商都積極參與才能把新功能寫進規范。

以下是一些新功能。

目前，WebAssembly 沒有任何方式能夠操作 DOM 。所以我們不能像使用 element.innerHTML 一樣，從 WebAssembly 里更新一個 DOM 節點。

相反，必須通過 JavaScript 才能改變 DOM 節點。
也就是說，必須把新值返回給 JavaScript 調用方。或者在 WebAssembly 中調用 JavaScript 函數。這是可以實現的，因為 JavaScript 和 WebAssembly 函數都可以做為 WebAssembly 模塊的導入。

不管使用哪種方式，繞道 JavaScript 肯定比直接操作 DOM 要慢。這就導致了部分 WebAssembly 應用可能會因此而推遲發布時間。

有一種提高運行速度的辦法是，使不同代碼同時并行運行。
不過這有時候可能會偷雞不成蝕把米，因為線程間通信可能比任務本身耗費的時間還多。

但是如果能夠在不同線程之間共享內存，那么這種情況就會好很多。為此，WebAssembly 可以使用 JavaScript 的新接口 SharedArrayBuffer 來實現內存共享。一旦瀏覽器開始支持 SharedArrayBuffer，WebAssembly 工作小組就立馬可以開始為之制定相關標準。

SIMD（Single Instruction, Multiple Data）是“單指令多數據”的縮寫。它是實現并行化的另一種方式。

SIMD 可以接受一個大型數據結構（比如一個包含不同數值的向量），然后對其中的不同數據同時應用相同的指令。這種方式可以大幅提升游戲或者 VR 中的各種復雜計算。

這對普通的網頁應用開發者可能沒那么重要。但是對于像游戲等多媒體應用開發者就顯得尤為重要了。

很多語言都支持異常處理，但是 WebAssembly 尚未有相關異常處理的規范。

如果你使用 Emscripten 編譯代碼，你會發現它會模擬某些編譯器優化級別的異常處理。
不過這會導致編譯變慢，但是你可以通過 DISABLE_EXCEPTION_CATCHING 標志來關閉它。

如果 WebAssembly 本身就能夠處理異常，那么這種異常模擬就沒必要了。

也有一些未來的功能并不會影響性能，但是卻能提升 WebAssembly 的開發體驗。

一等的源碼開發工具。目前，在瀏覽器中調試 WebAssembly 就像直接調試匯編。雖然還是能夠調試，但是基本上很少開發者能夠把它跟源碼關聯起來。所以，我們正在研究該如何改進工具支持，從而實現可以直接調試源碼。

垃圾回收。如果能夠事先定義數據的類型，那么就能夠把這類代碼變成 WebAssembly 。所以使用 TypeScript 這類語言編寫的代碼，是可以跟 WebAssembly 兼容的。不過，目前唯一的困難是 WebAssembly 還不知道該如何與現有的垃圾回收機制結合，就像 JavaScript 引擎內置的垃圾回收一樣。

ES6 模塊集成。瀏覽器目前正在完善使用 script 來加載模塊的功能。等到該功能完成后，把