為解決網頁應用程式的效能低落的原罪,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倍了。


Advertisement

更多 iThome相關內容