精讀《V8 引擎 Lazy Parsing》

1. 引言

本週精讀的文章是 V8 引擎 Lazy Parsing，看看 V8 引擎爲了優化性能，作了怎樣的嘗試吧！

這篇文章介紹的優化技術叫 preparser，是經過跳過沒必要要函數編譯的方式優化性能。

2. 概述 & 精讀

解析 Js 發生在網頁運行的關鍵路徑上，所以加速對 JS 的解析，就能夠加速網頁運行效率。

然而並非全部 Js 都須要在初始化時就被執行，所以也不須要在初始化時就解析全部的 Js！由於編譯 Js 會帶來三個成本問題：

1. 編譯沒必要要的代碼會佔用 CPU 資源。
2. 在 GC 前會佔用沒必要要的內存空間。
3. 編譯後的代碼會緩存在磁盤，佔用磁盤空間。

所以全部主流瀏覽器都實現了 Lazy Parsing（延遲解析），它會將沒必要要的函數進行預解析，也就是隻解析出外部函數須要的內容，而全量解析在調用這個函數時才發生。

預解析的挑戰

原本預解析也不難，由於只要判斷一個函數是否會當即執行就能夠了，只有當即執行的函數才須要被徹底解析。

使得預解析變複雜的是變量分配問題。原文經過了堆棧調用的例子說明緣由：

Js 代碼的執行在堆棧上完成，好比下面這個函數：

function f(a, b) {
  const c = a + b;
  return c;
}

function g() {
  return f(1, 2);
  // The return instruction pointer of `f` now points here
  // (because when `f` `return`s, it returns here).
}

這段函數的調用堆棧以下：

首先是全局 This globalThis，而後執行到函數 f，再對 a b 進行賦值。在執行 f 函數時，經過 <rip g>(return instruction pointer) 保存 g 堆棧狀態，再保存堆棧跳出後返回位置的指針 <save fp>(frame pointer)，最後對變量 c 賦值。

這看上去沒有問題，只要將值存在堆棧就搞定了。可是將變量定義到函數內部就不同了：

function make_f(d) {
  // ← declaration of `d`
  return function inner(a, b) {
    const c = a + b + d; // ← reference to `d`
    return c;
  };
}

const f = make_f(10);

function g() {
  return f(1, 2);
}

將變量 d 申明在函數 make_f 中，且在返回函數 inner 中用到了 d。那麼函數的調用棧就變成了這樣：

須要建立一個 context 存儲函數 f 中變量 d 的值。

也就是說，若是一個在函數內部定義的變量被子 Scope 使用時，Js 引擎須要識別這種狀況，並將這個變量值存儲在 context 中。

因此對於函數定義的每個入參，咱們須要知道其是否會被子函數引用。也就是說，在 preparser 階段，咱們只要少能分析出哪些變量被內部函數引用了。

難以分辨的引用

預處理器中跟蹤變量的申明與引用很複雜，由於 Js 的語法致使了沒法從部分表達式推斷含義，好比下面的函數：

function f(d) {
  function g() {
    const a = ({ d }

咱們不清楚第三行的 d 究竟是不是指代第一行的 d。它多是：

function f(d) {
  function g() {
    const a = ({ d } = { d: 42 });
    return a;
  }
  return g;
}

也可能只是一個自定義函數參數，與上面的 d 無關：

function f(d) {
  function g() {
    const a = ({ d }) => d;
    return a;
  }

  return [d, g];
}

惰性 parse

在執行函數時，只會將最外層執行的函數徹底編譯並生成 AST，而對內部模塊只進行 preparser。

// This is the top-level scope.
function outer() {
  // preparsed
  function inner() {
    // preparsed
  }
}

outer(); // Fully parses and compiles `outer`, but not `inner`.

爲了容許惰性編譯函數，上下文指針指向了 ScopeInfo 的對象（從代碼中能夠看到，ScopeInfo 包含上下文信息，好比當前上下文是否有函數名，是否在一個函數內等等），當編譯內部函數時，能夠利用 ScopeInfo 繼續編譯子函數。

可是爲了判斷惰性編譯函數自身是否須要一個上下文，咱們須要再次解析內部的函數：好比咱們須要知道某個子函數是否對外層函數定義的變量有所引用。

這樣就會產生遞歸遍歷：

因爲代碼總會包含一些嵌套，而編譯工具更會產生 IIFE(當即調用函數) 這種多層嵌套的表達式，使得遞歸性能比較差。

而下面有一種辦法能夠將時間複雜度簡化爲線性：將變量分配的位置序列化爲一個密集的數組，當惰性解析函數時，變量會按照原先的順序從新建立，這樣就不須要由於子函數可能引用外層定義變量的緣由，對全部子函數進行遞歸惰性解析了。

按照這種方式優化後的時間複雜度是線性的：

針對模塊化打包的優化

因爲現代代碼幾乎都是模塊化編寫的，構建起在打包時會將模塊化代碼封裝在 IIFE（當即調用的閉包）中，以保證模擬模塊化環境運行。好比 (function(){....})()。

這些代碼看似在函數中應該惰性編譯，但其實這些模塊化代碼從一開始就要被編譯，不然反而會影響性能，所以 V8 有兩種機制識別這些可能被當即調用的函數：

1. 若是函數是帶括號的，好比 (function(){...})，就假設它會被當即調用。
2. 從 V8 v5.7 / Chrome 57 開始，還會識別 uglifyJS 的 !function(){...}(), function(){...}(), function(){...}() 這種模式。

然而在瀏覽器引擎解析環境比較複雜，很難對函數進行完整字符串匹配，所以只能對函數頭進行簡單判斷。因此對於下面這種匿名函數的行爲，瀏覽器是不識別的：

// pre-parser
function run(func) {
  func()
}

run(function(){}) // 在這執行它，進行 full parser

上面的代碼看上去沒毛病，但因爲瀏覽器只檢測被括號括住的函數，所以這個函數不被認爲是當即執行函數，所以在後續執行時會被重複 full-parse。

也有一些代碼輔助轉換工具幫助 V8 正確識別，好比 optimize-js，會將代碼作以下轉換。

轉換前：

!function (){}()
function runIt(fun){ fun() }
runIt(function (){})

轉換後：

!(function (){})()
function runIt(fun){ fun() }
runIt((function (){}))

然而在 V8 v7.5+ 已經很大程度解決了這個問題，所以如今其實不須要使用 optimize-js 這種庫了～

4. 總結

JS 解析引擎在性能優化作了很多工做，但同時也要應對代碼編譯器產生的特殊 IIFE 閉包，防止對這種當即執行閉包進行重複 parser。

最後，不要試圖老是將函數用括號括起來，由於這樣會致使惰性編譯的特性沒法啓用。

討論地址是：精讀《V8 引擎 Lazy Parsing》 · Issue #148 · dt-fe/weekly

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

special Sponsors

• DevOps 全流程平臺

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）