【譯】使用"BinaryAST"加快JavaScript腳本的解析速度？

原文地址：blog.cloudflare.com/binary-ast/

本文首發於公衆號：符合預期的CoyPan

JavaScirpt的冷啓動

web應用的表現，愈來愈受制於啓動時間。咱們已經習慣於使用大量的JavaScript代碼來開發豐富的web交互體驗。從HTTPArchive上，咱們能夠看到，一個移動設備平均會加載350KB的JavaSript代碼，10%的頁面會加載超過1MB的JavaScipt代碼。複雜的交互會使得這個數字愈來愈高。

儘管有緩存的幫助，可是常見的站點都會頻繁的發佈新代碼，致使冷啓動(首次加載)時間十分的重要。隨着瀏覽器將緩存按照域來劃分以防止跨站點泄露，冷啓動的重要性正在增長，即便是從CDN加載的經常使用資源來講也是如此，由於它們再也不可以安全地共享。

一般狀況下，當咱們談論冷啓動性能時，最多見的因素就是下載速度。而後，在如今的富交互頁面上，另一個影響冷啓動的很重要因素是：JavaScipt的解析時間。咋看起來會有點讓人意外，可是是合理的：在開始執行代碼前，引擎不得不先解析下載的JavaScript，確保腳本沒有語法錯誤，而後將其編譯爲基本的字節碼。隨着網絡變得愈來愈快，JavaScipt的解析和編譯可能會成爲影響冷啓動的最主要因素。

設備能力（CPU或內存性能）是影響JavaScript解析時間和相應應用程序啓動時間變化的最重要因素。在現代桌面或高端移動設備上，一個1MB的javascript文件須要100毫秒的解析時間，但在普通手機上，解析時間能夠超過一秒鐘。

關於在不一樣設備上javascript解析、編譯和執行的整體成本，這篇文章給出了詳細的介紹。以news.google.com爲例，在Pixel 2上，解析、編譯、執行JS的總耗時爲4s，而在一些低端的設備上，須要28s。

雖然引擎不斷提升原始解析性能，尤爲是在過去的一年裏，V8引擎的性能翻了一番，而且使更多的東西脫離了主線程，但解析器仍然須要作大量可能沒必要要的工做，這些工做會消耗內存、電池，並可能延遲有用資源的處理。

BinaryAST提案

"BinaryAST"應運而生。BinaryAST是Mozilla提出並積極開發的一種新的在線javascript格式，旨在加快解析速度，同時保持原始javascript的語義不變。它的實現方式是：使用有效的二進制來表示代碼和數據結構，而且存儲和提供額外的信息來提早指導解析器工做。

之因此使用BinaryAST這個名字，是由於這種格式以AST的方式存儲JavaScript源碼，而後編碼到一個二進制文件中。該規範位於tc39.github.io/proposal-bi…，目前正由Mozilla、Facebook、Bloomberg和CloudFlare的工程師開發。

解析JavaScript

對於要在瀏覽器中執行的常規JavaScript代碼，源代碼被解析爲一個稱爲AST的中間表示，它描述了代碼的語法結構。而後，能夠將此AST編譯爲字節代碼或本機代碼以供執行。

一段簡單的將兩個數相加的代碼，用AST表示爲：

解析JavaScript不是一項簡單的任務；不管使用哪一種優化，它仍然須要逐字符讀取整個文本文件，同時跟蹤額外的上下文進行語法分析。

BinaryAST的目標是經過在解析器須要的時間和地點提供額外的信息和上下文，來下降複雜性和瀏覽器解析器必須完成的整體工做量。

要執行以BinaryAST方式傳遞的JavaScript，所須要的惟一步驟是：

BinaryAST的另外一個好處是它能夠只解析啓動所需的關鍵代碼，徹底跳過未使用的位。這能夠顯著提升初始加載時間。

這篇文章將更加詳細地描述解析JavaScipt時遇到的挑戰，解釋咱們是如何克服這些問題的，以及咱們是如何在Worker中運行代碼解釋器的。

提高

JavaScript依賴於提高全部聲明——變量、函數、類。提高是語言的一個屬性，它容許你在語法上使用以後，再去聲明變量，函數，類等。

讓咱們來看下面這個例子：

function f() {
	return g();
}

function g() {
	return 42;
}
複製代碼

在這裏，當解析器查看F的主體時，它還不知道G指的是什麼——它多是一個已經存在的全局函數或者在同一個文件中進一步聲明的某個函數——因此它沒法最終解析原始函數並開始實際編譯。

BinaryAST經過存儲全部做用域信息並使其在實際表達式以前可用來解決這個問題。

用JSON表示初始的AST和加強的AST以前的區別，以下圖所示：

延遲解析

現代引擎用來改進解析時間的一種常見技術是延遲解析。它利用了這樣一個事實：許多網站包含的javascript比實際須要的要多，特別是對於新的網站。

例如，從文本中解析數字、布爾值甚至字符串等低級類型須要額外的分析和計算。這是沒有必要的。您能夠首先將它們存儲和讀取爲本機二進制編碼值，而後直接在另外一端讀取。

另外一個問題是語法自己的歧義。這在ES5世界中已是一個問題，但一般能夠經過一些基於之前看到的標記的額外記錄來解決。然而，在ES6+中，有些東西可能一直模糊不清，直到它們被徹底解析爲止。

例如，一個標記序列以下：

(a, {b: c, d}, [e = 1])...
複製代碼

上述標記序列能夠是一個用嵌套的對象和數組文本以及賦值來啓動帶括號的逗號表達式：

(a, {b: c, d}, [e = 1]); // 這是一個表達式
複製代碼

也能夠是一個帶有嵌套對象和數組模式的箭頭表達式函數的參數列表和默認值：

(a, {b: c, d}, [e = 1]) => … // 這是一個參數列表
複製代碼

這兩種表示都是徹底有效的，但語義徹底不一樣，在看到最後一個標記以前，你沒法知道要處理的是哪一個。

爲了解決這一問題，解析器一般要麼回溯，這很容易以指數級的速度變慢，要麼將內容解析爲可以同時保存表達式和模式的中間節點類型，並進行後續的轉換。後一種方法保留了線性性能，但使實現更加複雜，須要保留更多的狀態。

在BinaryAST格式下，這個問題再也不存在。由於解析器在開始解析內容前就能夠看到每一個節點的類型。

展現實驗數據

請記住，該提案處於很是早期的階段，當前的基準和演示不能表明最終結果。

如前所述，BinaryAST能夠標記應該提早進行惰性分析的函數。經過在編碼器中使用不一樣級別的惰性化，對一些流行的javascript庫運行測試時，咱們發現瞭如下速度的提高。

Level 0 (no functions are lazified)

在兩個解析器中都禁用了惰性解析以後，原始解析速度提升了3%到10%。

Level 3 (functions up to 3 levels deep are lazified)

可是，經過設置爲跳過最多嵌套3層的函數函數，咱們能夠看到解析時間在90%到97%之間的顯著改進。正如本文前面提到的，BinaryAST經過徹底跳過標記的函數，使延遲解析基本上是無開銷的。

經過下面的包含1.2MB JavaScript的示例程序

github.com/cloudflare/…

serve-binjs.that-test.site/

咱們獲得瞭如下的初始腳本執行數據：

如下是一段視頻，它將讓您瞭解移動FireFox用戶所看到的改進（在本例中，顯示整個頁面啓動時間）：

下一步是開始在現實網站上收集數據，同時改進底層格式。

如何在個人站點上測試BinaryAST？

咱們已經開源了Worker的源代碼，以便將其安裝到任何CloudFlare區域：

github.com/binast/binj…

目前須要注意的一件事是，即便結果存儲在緩存中，初始編碼仍然是一個昂貴的過程，而且可能很容易達到任何重要的javascript文件的CPU限制，並返回到未編碼的變量。咱們正在努力改善這種狀況，在接下來的日子裏，將BinaryAST編碼器做爲一個單獨的功能發佈，並有更寬鬆的限制。

同時，若是你想在更大的腳本上使用BinaryAST，另外一種選擇是使用https://github.com/binast/binjs-ref中的binjs_encode工具，提早對javascript文件進行預編碼。而後，在瀏覽器支持和請求時，可使用https://github.com/cloudflare/binast-cf-worker中的Worker，來處理生成的BinaryAST文件。

在客戶端，您當前須要下載Firefox Nightly，轉到about:config並經過如下選項啓用無限制的binaryast支持。

如今，當打開一個安裝了Worker的網站時，Firefox會自動獲得BinaryAST而不是javascript。

總結

現代應用程序中的javascript數量正在給全部消費者帶來性能挑戰。引擎供應商正在嘗試各類不一樣的方法來改善這種狀況——一些側重於原始解碼性能，一些側重於並行操做以減小整體延遲，一些致力於研究用於數據表示的新的優化格式，還有一些正在發明和改進用於網絡交付的協議。

不論是哪個，咱們都有一個共同的目標，那就是讓網絡變得更好、更快。