https://www.zcfy.cc/article/an-abridged-cartoon-introduction-to-webassembly-ndash-smashing-magazine

圖說 WebAssembly

原文鏈接： www.smashingmagazine.com

最近，WebAssembly 在 JavaScript 圈非常的火！人們都在談?wù)撍嗝炊嗝纯?#xff0c;怎樣怎樣改變 Web 開發(fā)領(lǐng)域。但是沒有人講他到底為什么那么快。在這篇文章里，我將會(huì)幫你了解 WebAssembly 到底為什么那么快。

第一，我們需要知道它到底是什么！WebAssembly 是一種可以使用非 JavaScript 編程語言編寫代碼并且能在瀏覽器上運(yùn)行的技術(shù)方案。

（看大圖）

當(dāng)大家談?wù)撈?WebAssembly 時(shí)，首先想到的就是 JavaScript。現(xiàn)在，我沒有必須在 WebAssembly 和 JavaScript 中選一個(gè)的意思。實(shí)際上，我們期待開發(fā)者在一個(gè)項(xiàng)目中把 WebAssembly 和 JavaScript 結(jié)合使用。但是，比較這兩者是有用的，這對(duì)你了解 WebAssembly 有一定幫助。

拓展閱讀閱讀：

一點(diǎn)點(diǎn)性能歷史

1995 年 JavaScript 誕生。它的設(shè)計(jì)時(shí)間非常短，前十年發(fā)展迅速。

緊接著瀏覽器廠商們就開始了更多的競(jìng)爭(zhēng)。

2008年，人們稱之為瀏覽器性能大戰(zhàn)的時(shí)期開始了。很多瀏覽器加入了即時(shí)編譯器，又稱之為JITs。在這種模式下，JavaScript在運(yùn)行的時(shí)候，JIT 選擇模式然后基于這些模式使代碼運(yùn)行更快。

這些 JITs 的引入是瀏覽器運(yùn)行代碼機(jī)制的一個(gè)轉(zhuǎn)折點(diǎn)。所有的突然之間，JavaScript 的運(yùn)行速度快了10倍。

（看大圖）

隨著這種改進(jìn)的性能，JavaScript 開始被用于意想不到的事情，比如使用Node.js和Electron構(gòu)建應(yīng)用程序。

現(xiàn)在 WebAssembly 可能是的另一個(gè)轉(zhuǎn)折點(diǎn)。

（看大圖）

在我們沒有搞清楚 JavaScript 和 WebAssembly 之間的性能差前，我們需要理解 JS 引擎所做的工作。

JavaScript 是如何在瀏覽器中運(yùn)行的呢？

作為一個(gè)開發(fā)人員，您將JavaScript添加到頁面時(shí)，您有一個(gè)目標(biāo)并遇到一個(gè)問題。

• 目標(biāo)：你想要告訴計(jì)算機(jī)做什么
• 問題：你和計(jì)算機(jī)使用不通的語言。

您說的是人類的語言，計(jì)算機(jī)說的是機(jī)器語言。盡管你不認(rèn)為 JavaScript 或者其他高級(jí)語言是人類語言，但事實(shí)就是這樣的。它們的設(shè)計(jì)是為了讓人們認(rèn)知，不是為機(jī)器設(shè)計(jì)的。

所以JavaScript引擎的工作就是把你的人類語言轉(zhuǎn)化成機(jī)器所理解的語言。

我想到電影《Arrival》，這就像人類和外星人進(jìn)行交談。

（看大圖）

在這部電影中，人類語言不能從逐字翻譯成外星語言。他們的語言反映出兩種對(duì)世界不同的認(rèn)知。人類和機(jī)器也是這樣。

所以，怎么進(jìn)行翻譯呢？

在編程中，通常有兩種翻譯方法將代碼翻譯成機(jī)器語言。你可以使用解釋器或者編譯器。

使用解釋器，翻譯的過程基本上是一行一行及時(shí)生效的。

（看大圖）

編譯器是另外一種工作方式，它在執(zhí)行前翻譯。

（看大圖）

每種翻譯方法都有利弊。

解釋器的利弊

解釋器很快的獲取代碼并且執(zhí)行。您不需要在您可以執(zhí)行代碼的時(shí)候知道全部的編譯步驟。因此，解釋器感覺與 JavaScript 有著自然的契合。web 開發(fā)者能夠立即得到反饋很重要。

這也是瀏覽器最開始使用 JavaScript 解釋器的原因之一。

但是使用解釋器的弊端是當(dāng)您運(yùn)行相同的代碼的時(shí)候。比如，您執(zhí)行了一個(gè)循環(huán)。然后您就會(huì)一遍又一遍的做同樣的事情。

編譯器的利弊

編譯器則有相反的效果。在程序開始的時(shí)候，它可能需要稍微多一點(diǎn)的時(shí)間來了解整個(gè)編譯的步驟。但是當(dāng)運(yùn)行一個(gè)循環(huán)的時(shí)候他會(huì)更快，因?yàn)樗恍枰貜?fù)的去翻譯每一次循環(huán)里的代碼。

因?yàn)榻忉屍鞅仨氃诿看窝h(huán)訪問時(shí)不斷重新轉(zhuǎn)換代碼，作為一個(gè)可以擺脫解釋器低效率的方法，瀏覽器開始將編譯器引入。

不同的瀏覽器實(shí)現(xiàn)起來稍有不同，但是基本目的是相同的。他們給 JavaScript 引擎添加了一個(gè)新的部分，稱為監(jiān)視器（也稱為分析器）。該監(jiān)視器在 JavaScript 運(yùn)行時(shí)監(jiān)控代碼，并記錄代碼片段運(yùn)行的次數(shù)以及使用了那些數(shù)據(jù)類型。

如果相同的代碼行運(yùn)行了幾次，這段代碼被標(biāo)記為 “warm”。如果運(yùn)行次數(shù)比較多，就被標(biāo)記為 “hot”。
被標(biāo)記為 “warm” 的代碼被扔給基礎(chǔ)編譯器，只能提升一點(diǎn)點(diǎn)的速度。被標(biāo)記為 “hot” 的代碼被扔給優(yōu)化編譯器，速度提升的更多。

（看大圖）

了解更多，可以讀 https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/

耗時(shí)比較：JavaScript Vs. WebAssembly

這張圖大致給出了現(xiàn)在一個(gè)程序的啟動(dòng)性能，目前 JIT 編譯器在瀏覽器中很常見。

該圖顯示了 JS 引擎運(yùn)行程序花費(fèi)的時(shí)間。顯示的時(shí)間并不是平均的。這個(gè)圖片表明，JS 引擎做的這些任務(wù)花費(fèi)的時(shí)間取決于頁面中 JavaScript 做了什么事情。但是我們可以用這個(gè)圖來構(gòu)建一個(gè)心理模型。

（看大圖）

每欄顯示花費(fèi)在特定任務(wù)上的時(shí)間。

• Parsing - 講源碼轉(zhuǎn)換成解釋器可以運(yùn)行的東西所用的事情。

• Compiling + optimizing - 花費(fèi)在基礎(chǔ)編譯和優(yōu)化編譯上的時(shí)間。有一些優(yōu)化編譯的工作不在主線程，所以這里并不包括這些時(shí)間。

• Re-optimizing - 當(dāng)預(yù)先編譯優(yōu)化的代碼不能被優(yōu)化的情況下，JIT 將這些代碼重新優(yōu)化，如果不能重新優(yōu)化那么久丟給基礎(chǔ)編譯去做。這個(gè)過程叫做重新優(yōu)化。
• Execution - 執(zhí)行代碼的過程
• Garbage collection - 清理內(nèi)存的時(shí)間

一個(gè)重要的事情要注意：這些任務(wù)不會(huì)發(fā)生在離散塊或特定的序列中。相反，它們將被交叉執(zhí)行。比如正在做一些代碼解析時(shí)，還執(zhí)行者一些其他的邏輯，有些代碼編譯完成后，引擎又做了一些解析，然后又執(zhí)行了一些邏輯，等等。

這種交叉執(zhí)行對(duì)早期 JavaScript 的性能有很大的幫助，早期的 JavaScript 的執(zhí)行就像下圖一樣：

（看大圖）

一開始，當(dāng)只有一個(gè)解釋器運(yùn)行 JavaScript 時(shí)，執(zhí)行速度相當(dāng)緩慢。JITs 的引入，大大提升了執(zhí)行效率。

監(jiān)視和編譯代碼的開銷是需要權(quán)衡的事情。如果 JavaScript 開發(fā)人員按照相同的方式編寫JavaScript，解析和編譯時(shí)間將會(huì)很小。但是，性能的提升使開發(fā)人員能夠創(chuàng)建更大的JavaScript應(yīng)用程序。

這意味著還有改進(jìn)的余地。

下面是 WebAssembly 如何比較典型 web 應(yīng)用。

（看大圖）

瀏覽器的 JS 引擎有輕微的不同。我是基于 SpiderMonkey 來講。

請(qǐng)求

這沒有展示在圖上，但是從服務(wù)器獲取文件是會(huì)消耗時(shí)間的

下載執(zhí)行與 JavaScript 等效的 WebAssembly 文件需要更少的時(shí)間，因?yàn)樗捏w積更小。WebAssembly 設(shè)計(jì)的體積更小，可以以二進(jìn)制形式表示。

即使使用 gzip 壓縮的 JavaScript文件很小，但 WebAssembly 中的等效代碼可能更小。

所以說，下載資源的時(shí)間會(huì)更少。在網(wǎng)速慢的情況下更能顯示出效果來。

解析

JavaScript 源碼一旦被下載到瀏覽器，源將被解析為抽象語法樹（AST）。

通常瀏覽器解析源碼是懶惰的，瀏覽器首先會(huì)解析他們真正需要的東西，沒有及時(shí)被調(diào)用的函數(shù)只會(huì)被創(chuàng)建成存根。

在這個(gè)過程中，AST被轉(zhuǎn)換為該 JS 引擎的中間表示（稱為字節(jié)碼）。

相反，WebAssembly 不需要被轉(zhuǎn)換，因?yàn)樗呀?jīng)是字節(jié)碼了。它僅僅需要被解碼并確定沒有任何錯(cuò)誤。

（看大圖）

編譯 + 優(yōu)化

如前所述，JavaScript 是在執(zhí)行代碼期間編譯的。因?yàn)?JavaScript 是動(dòng)態(tài)類型語言，相同的代碼在多次執(zhí)行中都有可能都因?yàn)榇a里含有不同的類型數(shù)據(jù)被重新編譯。這樣會(huì)消耗時(shí)間。

相反，WebAssembly 與機(jī)器代碼更接近。例如，類型是程序的一部分。這是速度更快的一個(gè)原因：

• 編譯器不需要在運(yùn)行代碼時(shí)花費(fèi)時(shí)間去觀察代碼中的數(shù)據(jù)類型，在開始編譯時(shí)做優(yōu)化。

• 編譯器不需要去每次執(zhí)行相同代碼中數(shù)據(jù)類型是否一樣。

• 更多的優(yōu)化在 LLVM 最前面就已經(jīng)完成了。所以編譯和優(yōu)化的工作很少。

（看大圖）

重新優(yōu)化

有時(shí) JIT 拋出一個(gè)優(yōu)化版本的代碼，然后重新優(yōu)化。

JIT 基于運(yùn)行代碼的假設(shè)不正確時(shí)，會(huì)發(fā)生這種情況。例如，當(dāng)進(jìn)入循環(huán)的變量與先前的迭代不同時(shí)，或者在原型鏈中插入新函數(shù)時(shí)，會(huì)發(fā)生重新優(yōu)化。

在 WebAssembly 中，類型是明確的，因此 JIT 不需要根據(jù)運(yùn)行時(shí)收集的數(shù)據(jù)對(duì)類型進(jìn)行假設(shè)。這意味著它不必經(jīng)過重新優(yōu)化的周期。

（看大圖）

執(zhí)行

盡可能編寫執(zhí)行性能好的 JavaScript。所以，你可能需要知道 JIT 是如何做優(yōu)化的。

然而，大多數(shù)開發(fā)者并不知道 JIT 的內(nèi)部原理。即使是那些了解 JIT 內(nèi)部原理的開發(fā)人員，也很難實(shí)現(xiàn)最佳的方案。有很多時(shí)候，人們?yōu)榱耸顾麄兊拇a更易于閱讀（例如：將常見任務(wù)抽象為跨類型工作的函數(shù)）會(huì)阻礙編譯器優(yōu)化代碼。

正因如此，執(zhí)行 WebAssembly 代碼通常更快。有些必須對(duì) JavaScript 做的優(yōu)化不需要用在 WebAssembly 上

另外，WebAssembly 是為編譯器設(shè)計(jì)的。意思是，它是專門給編譯器來閱讀，并不是當(dāng)做編程語言讓程序員去寫的。

由于程序員不需要直接編程，WebAssembly 提供了一組更適合機(jī)器的指令。根據(jù)您的代碼所做的工作，這些指令的運(yùn)行速度可以在10％到800％之間。

（看大圖）

垃圾回收

在 JavaScript 中，開發(fā)者不需要擔(dān)心內(nèi)存中無用變量的回收。JS 引擎使用一個(gè)叫垃圾回收器的東西來自動(dòng)進(jìn)行垃圾回收處理。

這對(duì)于控制性能可能并不是一件好事。你并不能控制垃圾回收時(shí)機(jī)，所以它可能在非常重要的時(shí)間去工作，從而影響性能。

現(xiàn)在，WebAssembly 根本不支持垃圾回收。內(nèi)存是手動(dòng)管理的（就像 C/C++）。雖然這些可能讓開發(fā)者編程更困難，但它的確提升了性能。

（看大圖）

總而言之，這些都是在許多情況下，在執(zhí)行相同任務(wù)時(shí)WebAssembly 將勝過 JavaScript 的原因。

在某些情況下，WebAssembly 不能像預(yù)期的那樣執(zhí)行，還有一些更改使其更快。我在另一篇文章中更深入地介紹了這些未來的功能。

WebAssembly 是如何工作的？

現(xiàn)在，您了解開發(fā)人員為什么對(duì) WebAssembly 感到興奮，讓我們來看看它是如何工作的。

當(dāng)我談到上面的 JIT 時(shí)，我談到了與機(jī)器的溝通像與外星人溝通。

（看大圖）

我現(xiàn)在想看看這個(gè)外星人的大腦如何工作 - 機(jī)器的大腦如何解析和理解交流內(nèi)容。

這個(gè)大腦的一部分是專注于思考，例如算術(shù)和邏輯。有一部分腦部提供短期記憶，另一部分提供長(zhǎng)期記憶。

這些不同的部分都有名字。

• 負(fù)責(zé)思考的部分是算術(shù)邏輯單元（ALU）。
• 短期儲(chǔ)存由寄存器（Registers）提供。
• 隨機(jī)存儲(chǔ)器（或RAM）來提供長(zhǎng)期儲(chǔ)存能力。

（看大圖）

機(jī)器碼中的語句被稱為指令。

當(dāng)一條指令進(jìn)入大腦時(shí)會(huì)發(fā)生什么？它被拆分成了多個(gè)的部分并有特殊的含義。

被拆分成的多個(gè)部分分別進(jìn)入不同的大腦單元進(jìn)行處理，這也是拆分指令所依賴的方式。

例如，這個(gè)大腦從機(jī)器碼中取出4-10位，并將它們發(fā)送到 ALU。ALU進(jìn)行計(jì)算，它根據(jù) 0 和 1 的位置來確定是否需要將兩個(gè)數(shù)相加。

這個(gè)塊被稱為“操作碼”，因?yàn)樗嬖V ALU 執(zhí)行什么操作。

（看大圖）

那么這個(gè)大腦會(huì)拿后面的兩個(gè)塊來確定他們所要操作的數(shù)。這兩個(gè)塊對(duì)應(yīng)的是寄存器的地址。

（看大圖）

請(qǐng)注意添加在機(jī)器碼上面的標(biāo)注（ADD R1 R2），這使我們更容易了解發(fā)生了什么。這就是匯編。它被稱為符號(hào)機(jī)器碼。這樣人類也能看懂機(jī)器碼的含義。

您可以看到，這個(gè)機(jī)器的匯編和機(jī)器碼之間有非常直接的關(guān)系。每種機(jī)器內(nèi)部有不同的結(jié)構(gòu)，所以每種機(jī)器都有自己獨(dú)有的匯編語言。

所以我們并不只有一個(gè)翻譯的目標(biāo)。
相反，我們的目標(biāo)是不同類型的機(jī)器碼。就像人類說不同的語言一樣，機(jī)器也有不同的語言。

您希望能夠?qū)⑦@些任何一種高級(jí)編程語言轉(zhuǎn)換為任何一種匯編語言。這樣做的一個(gè)方法是創(chuàng)建一大堆不同的翻譯器，可以從任意一種語言轉(zhuǎn)換成任意一種匯編語言。

（看大圖）

這樣做的效率非常低。為了解決這個(gè)問題，大多數(shù)編譯器會(huì)在高級(jí)語言和匯編語言之間多加一層。編譯器將把高級(jí)語言翻譯成一種更低級(jí)的語言，但比機(jī)器碼的等級(jí)高。這就是中間代碼（IR）。

（看大圖）

意思就是編譯器可以將任何一種高級(jí)語言轉(zhuǎn)換成一種中間語言。然后，編譯器的另外的部分將中間語言編譯成目標(biāo)機(jī)器的匯編代碼。

編譯器的“前端”將高級(jí)編程語言轉(zhuǎn)換為IR。編譯器的“后端”將 IR 轉(zhuǎn)換成目標(biāo)機(jī)器的匯編代碼。

（看大圖）

WebAssembly 適合在哪里使用？

您可能會(huì)將 WebAssembly 當(dāng)做是另外一種目標(biāo)匯編語言。這是真的，這些機(jī)器語言（x86，ARM等）中的每一種都對(duì)應(yīng)于特定的機(jī)器架構(gòu)。

當(dāng)你的代碼運(yùn)行在用戶的機(jī)器的 web 平臺(tái)上的時(shí)候，你不知道你的代碼將會(huì)運(yùn)行在那種機(jī)器結(jié)構(gòu)上。

所以 WebAssembly 和別的匯編語言是有一些不同的。所以他是一個(gè)概念機(jī)上的機(jī)器語言，不是在一個(gè)真正存在的物理機(jī)上運(yùn)行的機(jī)器語言。

正因如此，WebAssembly 指令有時(shí)候被稱為虛擬指令。它比 JavaScript 代碼更快更直接的轉(zhuǎn)換成機(jī)器代碼，但它們不直接和特定硬件的特定機(jī)器代碼對(duì)應(yīng)。

在瀏覽器下載 WebAssembly后，使 WebAssembly 的迅速轉(zhuǎn)換成目標(biāo)機(jī)器的匯編代碼。

（看大圖）

如果想在您的頁面里上添加 WebAssembly，您需要將您的代碼編譯成 .wasm 文件。

編譯到 .wasm 文件

當(dāng)前對(duì) WebAssembly 支持最多的編譯器工具鏈稱是 LLVM。有許多不同的“前端”和“后端”可以插入到 LLVM 中。

注意：大多數(shù) WebAssembly 模塊開發(fā)者使用 C 和 Rust 編寫代碼，然后編譯成 WebAssembly，但是這里有其他創(chuàng)建 WebAssembly 模塊的途徑。比如，這里有一個(gè)實(shí)驗(yàn)性工具，他可以幫你使用 TypeScript 創(chuàng)建一個(gè) WebAssembly 模塊，你可以在這里直接編輯WebAssembly。

假設(shè)我們想通過 C 來創(chuàng)建 WebAssembly。我們可以使用 clang “前端” 從 C 編譯成 LLVM 中間代碼。當(dāng)它變成 LLVM 的中間代碼（IR）以后，LLVM 可以理解他，所以 LLVM 可以對(duì)代碼做一些優(yōu)化。

如果想讓 LLVM 的 IR 變成 WebAssembly，我們需要一個(gè) “后端”。目前 LLVM 項(xiàng)目中有一個(gè)正在開發(fā)中的。這個(gè)“后端”對(duì)做這件事情很重要，應(yīng)該很快就會(huì)完成。可惜，它現(xiàn)在還不能用。

另外有一個(gè)工具叫做 Emscripten，它用起來比較簡(jiǎn)單。它還可以有比較有用的可以選擇，比如說由 IndexDB 支持的文件系統(tǒng)。

（看大圖）

不管你使用的什么工具鏈，最終的結(jié)果都應(yīng)該是以 .wasm 結(jié)尾的文件。來讓我們看一下如何將它用在你的 web 頁面。

在 JavaScript 中加載一個(gè) .wasm 組件

.wasm 文件是 WebAssembly 組件，它可以被 JavaScript 加載。到目前為止，加載過程有點(diǎn)復(fù)雜。

function fetchAndInstantiate(url, importObject) {return fetch(url).then(response =>response.arrayBuffer()).then(bytes =>WebAssembly.instantiate(bytes, importObject)).then(results =>results.instance); }

您可以在文檔中更深入地了解這些。

我們正在努力使這個(gè)過程更容易。我們期望對(duì)工具鏈進(jìn)行改進(jìn)，并與現(xiàn)有的模塊管理工具（如Webpack）或加載器（如SystemJS）相結(jié)合。我相信，加載 WebAssembly 模塊越來越簡(jiǎn)單，就像加載 JavaScript 一樣。

但是，WebAssembly模塊和JS模塊之間存在重大差異。目前，WebAssembly 中的函數(shù)只能使用 WebAssembly 類型（整數(shù)或浮點(diǎn)數(shù)）作為參數(shù)或返回值。

（看大圖）

對(duì)于任何更復(fù)雜的數(shù)據(jù)類型（如字符串），必須使用 WebAssembly 模塊的內(nèi)存。

如果你之前主要使用 JavaScript，可能對(duì)于直接訪問內(nèi)存是不熟悉的。C，C ++和Rust等性能更高的語言往往具有手動(dòng)內(nèi)存管理功能。WebAssembly 模塊的內(nèi)存模擬這些語言中的堆。

為此，它使用 JavaScript 中稱為 ArrayBuffer。ArrayBuffer 是一個(gè)字節(jié)數(shù)組。因此，數(shù)組的索引作為內(nèi)存地址。

如果要在 JavaScript 和 WebAssembly 之間傳遞一個(gè)字符串，需要將字符轉(zhuǎn)換為等效的字符碼。然后你需要將它寫入內(nèi)存數(shù)組。由于索引是整數(shù)，所以可以將索引傳遞給 WebAssembly 函數(shù)。因此，字符串的第一個(gè)字符的索引可以當(dāng)作指針。

（看大圖）

任何人開發(fā)的 WebAssembly 模塊很可能被 Web 開發(fā)人員使用并為該模塊創(chuàng)建一個(gè)的裝飾器。這樣，您當(dāng)做用戶來使用這個(gè)模塊就不需要考慮內(nèi)存管理的事情了。

我已經(jīng)在另一篇文章中解釋了更多關(guān)于使用WebAssembly模塊的內(nèi)容。

WebAssembly 現(xiàn)在是什么狀態(tài)？

二月二十八日，四大瀏覽器宣布達(dá)成共識(shí)，即 WebAssembly 的 MVP （最小化可行產(chǎn)品）已經(jīng)完成。大約一周后，Firefox會(huì)默認(rèn)打開 WebAssembly 支持，而Chrome則在第二周開始。它也可用于預(yù)覽版本的Edge和Safari。

這提供了一個(gè)穩(wěn)定的初始版本，瀏覽器開始支持。

（看大圖）

該核心不包含社區(qū)組織計(jì)劃的所有功能。即使在初始版本中，WebAssembly 也會(huì)很快。但是，通過修復(fù)和新功能的組合，將來應(yīng)該能夠更快。我在另一篇文章中詳細(xì)介紹了這些功能。

總結(jié)

使用WebAssembly，可以更快地在 web 應(yīng)用上運(yùn)行代碼。這里有 幾個(gè) WebAssembly 代碼運(yùn)行速度比 JavaScript 高效的原因。

• 文件加載 - WebAssembly 文件體積更小，所以下載速度更快。
• 解析 - 解碼 WebAssembly 比解析 JavaScript 要快
• 編譯和優(yōu)化 - 編譯和優(yōu)化所需的時(shí)間較少，因?yàn)樵趯⑽募扑偷椒?wù)器之前已經(jīng)進(jìn)行了更多優(yōu)化，JavaScript 需要為動(dòng)態(tài)類型多次編譯代碼
• 重新優(yōu)化 - WebAssembly 代碼不需要重新優(yōu)化，因?yàn)榫幾g器有足夠的信息可以在第一次運(yùn)行時(shí)獲得正確的代碼
• 執(zhí)行 - 執(zhí)行可以更快，WebAssembly 指令更接近機(jī)器碼
• 垃圾回收 - 目前 WebAssembly 不直接支持垃圾回收，垃圾回收都是手動(dòng)控制的，所以比自動(dòng)垃圾回收效率更高。

目前瀏覽器中的 MVP（最小化可行產(chǎn)品） 已經(jīng)很快了。在接下來的幾年里，隨著瀏覽器的發(fā)展和新功能的增加，它將在未來幾年內(nèi)變得更快。沒有人可以肯定地說，這些性能改進(jìn)可以實(shí)現(xiàn)什么樣的應(yīng)用。但是，如果過去有任何跡象，我們可以期待驚奇。

(rb, ms, cm, il)

This article has been republished from Medium.

JavaScript 瀏覽器 程序員 C 設(shè)計(jì)

---

版權(quán)聲明

本譯文僅用于學(xué)習(xí)、研究和交流目的，歡迎非商業(yè)轉(zhuǎn)載。轉(zhuǎn)載請(qǐng)注明出處、譯者和眾成翻譯的完整鏈接。 眾成翻譯@2015-2018 （京ICP備17024260-1號(hào)）

轉(zhuǎn)載于:https://my.oschina.net/SamXIAO/blog/3071499

總結(jié)

以上是生活随笔為你收集整理的FW: 图说 WebAssembly的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。