WebAssembly執行速度真的比較快嗎？還真不一定

為解決網頁應用程式的效能低落的原罪，WebAssembly一直被視為救星，那實際使用的狀況如何呢？提供網頁PDF SDK的PSPDFKit為此做了實際測試，發現結果跟預期很不一樣，執行速度依瀏覽器以及作業系統不同而有很大的差異，唯有Firefox無論是在macOS或是Windows，執行WebAssembly速度都遠快於Javascript外，其他差異不大甚至還發生慢上許多的情況。PSPDFKit也將測試網頁釋出，供大家測試。

PSPDFKit在2016年釋出了他們第一個網頁SDK，而這是一個需要依賴伺服器元件來渲染文件的方法，因此當他們了解利用WebAssembly，能讓瀏覽器直接處理完所有渲染工作，不需要後端基礎設施，於是在積極研究下幾個月後，他們釋出基於WebAssembly的PSPDFKit網頁版本，以大幅降低客戶的使用障礙。

PSPDFKit網頁開發人員Philipp Spiess提到，選染PDF是一件復雜的事，除了PDF是一個存在25年的格式外，其中還有許多邊緣情況需要處理，總共需要約50萬行的C++程式碼來完成PDF渲染工作。但要將這些C++程式碼完全移植到JavaScript成本太高，他提到PSPDFKit不可能這麼做，而WebAssembly和asm.js等技術，允許他們在瀏覽器中使用相同的程式碼基底，將C++程式碼轉成WebAssembly程式，由瀏覽器快速渲染高傳真PDF檔案。

由於服務建構在WebAssembly基礎上，他們對於WebAssembly的執行效能非常在意，因此PSPDFKit對此進行了多瀏覽器多平臺的測試。他們想透過這個測試了解渲染情況，來提高網頁版PSPDFKit的執行效能，因此Philipp Spiess強調，這個測試講究應用程式實際執行的情況，測試得到的分數越低越好。

他還提到，用於測試的應用程式不會直接呼叫WebAssembly，反而還要先測試與之通訊的橋接部分，這樣才符合網頁版PSPDFKit 實際執行狀況。此外，這個測試還停用了WebAssembly的串流編譯功能，Philipp Spiess表示，這項功能讓WebAssembly和JavaScript-fallback1難以比較，因為JavaScript無法使用一邊串流同時編譯的最佳化，為了讓測試簡單易於比較，因此暫時停用了這項功能。

PSPDFKit在macOS與Windows兩大作業系統，測試了Chrome、Firefox、Safari和Edge四大熱門瀏覽器。結果顯示Firefox在兩個作業系統執行WebAssembly效能都是最好的，在macOS中，WebAssembly的執行效能分數1902，而JavaScript-fallback1則是6855（分數愈低愈好），而在Windows中則是1300比上4424，效率約快上3.5倍。

Philipp Spiess解釋，Firefox之所以測試結果可以這麼好，是因為採用了分層編譯以及IndexedDB記憶體。同時Firefox也給了PSPDFKit建議，在初始編譯時，瀏覽器基準編譯器（Baseline Compiler）啟動會比較慢，因此應該避免在第一次啟動時，在背景執行太多工作。

Chrome的情況則比較複雜一些，Chrome 67與Chrome 69金絲雀版本表現有些差異，在macOS中，Chrome 67執行WebAssembly分數5408略輸JavaScript-fallback1的4784，而Windows中WebAssembly分數3129則小贏JavaScript-fallback1的3373。

Philipp Spiess認為，Chrome的WebAssembly的執行效能一直以來比現不錯，但其V8引擎放棄為WebAssembly實作IndexedDB記憶體稍微可惜。不過，在他們與Google團隊連後，官方表示他們將在Chrome 69更新基準編譯器，因此Chrome 69加入測試後，無論在macOS或是Windows的WebAssembly執行效能皆獲提升，且於macOS平臺由輸轉贏。

值得注意的是，Safari即便在主場macOS上，WebAssembly的測試分數卻高達8382，執行速度低於JavaScript-fallback1的5802，在PSPDFKit與蘋果合作追蹤問題後，發現Safari存在一個臭蟲嚴重影響WebAssembly的表現，官方表示在修正後速度已經獲得提升，但沒有詳述分數。

另一個在圖表上吸引目光的項目則是微軟力推的Edge，WebAssembly在Windows的執行表現分數破萬11362，遠高於JavaScript-fallback1的7315，即便Edge執行Javascript的速度已是其他競爭對手慢2倍了。