1. 引言

本周精讀的文章是 V8 引擎 Lazy Parsing，看看 V8 引擎為了優(yōu)化性能，做了怎樣的嘗試吧！

這篇文章介紹的優(yōu)化技術(shù)叫 preparser，是通過(guò)跳過(guò)不必要函數(shù)編譯的方式優(yōu)化性能。

2. 概述 & 精讀

解析 Js 發(fā)生在網(wǎng)頁(yè)運(yùn)行的關(guān)鍵路徑上，因此加速對(duì) JS 的解析，就可以加速網(wǎng)頁(yè)運(yùn)行效率。

然而并不是所有 Js 都需要在初始化時(shí)就被執(zhí)行，因此也不需要在初始化時(shí)就解析所有的 Js！因?yàn)榫幾g Js 會(huì)帶來(lái)三個(gè)成本問(wèn)題：

編譯不必要的代碼會(huì)占用 CPU 資源。

在 GC 前會(huì)占用不必要的內(nèi)存空間。

編譯后的代碼會(huì)緩存在磁盤，占用磁盤空間。

因此所有主流瀏覽器都實(shí)現(xiàn)了 Lazy Parsing（延遲解析），它會(huì)將不必要的函數(shù)進(jìn)行預(yù)解析，也就是只解析出外部函數(shù)需要的內(nèi)容，而全量解析在調(diào)用這個(gè)函數(shù)時(shí)才發(fā)生。

預(yù)解析的挑戰(zhàn)

本來(lái)預(yù)解析也不難，因?yàn)橹灰袛嘁粋€(gè)函數(shù)是否會(huì)立即執(zhí)行就可以了，只有立即執(zhí)行的函數(shù)才需要被完全解析。

使得預(yù)解析變復(fù)雜的是變量分配問(wèn)題。原文通過(guò)了堆棧調(diào)用的例子說(shuō)明原因：

Js 代碼的執(zhí)行在堆棧上完成，比如下面這個(gè)函數(shù)：

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). }

這段函數(shù)的調(diào)用堆棧如下：

首先是全局 This globalThis，然后執(zhí)行到函數(shù) f，再對(duì) a b 進(jìn)行賦值。在執(zhí)行 f 函數(shù)時(shí)，通過(guò) <rip g>(return instruction pointer) 保存 g 堆棧狀態(tài)，再保存堆棧跳出后返回位置的指針 <save fp>(frame pointer)，最后對(duì)變量 c 賦值。

這看上去沒(méi)有問(wèn)題，只要將值存在堆棧就搞定了。但是將變量定義到函數(shù)內(nèi)部就不一樣了：

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 申明在函數(shù) make_f 中，且在返回函數(shù) inner 中用到了 d。那么函數(shù)的調(diào)用棧就變成了這樣：

需要?jiǎng)?chuàng)建一個(gè) context 存儲(chǔ)函數(shù) f 中變量 d 的值。

也就是說(shuō)，如果一個(gè)在函數(shù)內(nèi)部定義的變量被子 Scope 使用時(shí)，Js 引擎需要識(shí)別這種情況，并將這個(gè)變量值存儲(chǔ)在 context 中。

所以對(duì)于函數(shù)定義的每一個(gè)入?yún)?#xff0c;我們需要知道其是否會(huì)被子函數(shù)引用。也就是說(shuō)，在 preparser 階段，我們只要少能分析出哪些變量被內(nèi)部函數(shù)引用了。

難以分辨的引用

預(yù)處理器中跟蹤變量的申明與引用很復(fù)雜，因?yàn)?Js 的語(yǔ)法導(dǎo)致了無(wú)法從部分表達(dá)式推斷含義，比如下面的函數(shù)：

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

我們不清楚第三行的 d 到底是不是指代第一行的 d。它可能是：

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

也可能只是一個(gè)自定義函數(shù)參數(shù)，與上面的 d 無(wú)關(guān)：

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

惰性 parse

在執(zhí)行函數(shù)時(shí)，只會(huì)將最外層執(zhí)行的函數(shù)完全編譯并生成 AST，而對(duì)內(nèi)部模塊只進(jìn)行 preparser。

// This is the top-level scope. function outer() {// preparsedfunction inner() {// preparsed} }outer(); // Fully parses and compiles `outer`, but not `inner`.

為了允許惰性編譯函數(shù)，上下文指針指向了 ScopeInfo 的對(duì)象（從代碼中可以看到，ScopeInfo 包含上下文信息，比如當(dāng)前上下文是否有函數(shù)名，是否在一個(gè)函數(shù)內(nèi)等等），當(dāng)編譯內(nèi)部函數(shù)時(shí)，可以利用 ScopeInfo 繼續(xù)編譯子函數(shù)。

但是為了判斷惰性編譯函數(shù)自身是否需要一個(gè)上下文，我們需要再次解析內(nèi)部的函數(shù)：比如我們需要知道某個(gè)子函數(shù)是否對(duì)外層函數(shù)定義的變量有所引用。

這樣就會(huì)產(chǎn)生遞歸遍歷：

由于代碼總會(huì)包含一些嵌套，而編譯工具更會(huì)產(chǎn)生 IIFE(立即調(diào)用函數(shù)) 這種多層嵌套的表達(dá)式，使得遞歸性能比較差。

而下面有一種辦法可以將時(shí)間復(fù)雜度簡(jiǎn)化為線性：將變量分配的位置序列化為一個(gè)密集的數(shù)組，當(dāng)惰性解析函數(shù)時(shí)，變量會(huì)按照原先的順序重新創(chuàng)建，這樣就不需要因?yàn)樽雍瘮?shù)可能引用外層定義變量的原因，對(duì)所有子函數(shù)進(jìn)行遞歸惰性解析了。

按照這種方式優(yōu)化后的時(shí)間復(fù)雜度是線性的：

針對(duì)模塊化打包的優(yōu)化

由于現(xiàn)代代碼幾乎都是模塊化編寫的，構(gòu)建起在打包時(shí)會(huì)將模塊化代碼封裝在 IIFE（立即調(diào)用的閉包）中，以保證模擬模塊化環(huán)境運(yùn)行。比如 (function(){....})()。

這些代碼看似在函數(shù)中應(yīng)該惰性編譯，但其實(shí)這些模塊化代碼從一開始就要被編譯，否則反而會(huì)影響性能，因此 V8 有兩種機(jī)制識(shí)別這些可能被立即調(diào)用的函數(shù)：

如果函數(shù)是帶括號(hào)的，比如 (function(){...})，就假設(shè)它會(huì)被立即調(diào)用。

從 V8 v5.7 / Chrome 57 開始，還會(huì)識(shí)別 uglifyJS 的 !function(){...}(), function(){...}(), function(){...}() 這種模式。

然而在瀏覽器引擎解析環(huán)境比較復(fù)雜，很難對(duì)函數(shù)進(jìn)行完整字符串匹配，因此只能對(duì)函數(shù)頭進(jìn)行簡(jiǎn)單判斷。所以對(duì)于下面這種匿名函數(shù)的行為，瀏覽器是不識(shí)別的：

// pre-parser function run(func) {func() }run(function(){}) // 在這執(zhí)行它，進(jìn)行 full parser

上面的代碼看上去沒(méi)毛病，但由于瀏覽器只檢測(cè)被括號(hào)括住的函數(shù)，因此這個(gè)函數(shù)不被認(rèn)為是立即執(zhí)行函數(shù)，因此在后續(xù)執(zhí)行時(shí)會(huì)被重復(fù) full-parse。

也有一些代碼輔助轉(zhuǎn)換工具幫助 V8 正確識(shí)別，比如 optimize-js，會(huì)將代碼做如下轉(zhuǎn)換。

轉(zhuǎn)換前：

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

轉(zhuǎn)換后：

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

然而在 V8 v7.5+ 已經(jīng)很大程度解決了這個(gè)問(wèn)題，因此現(xiàn)在其實(shí)不需要使用 optimize-js 這種庫(kù)了～

4. 總結(jié)

JS 解析引擎在性能優(yōu)化做了不少工作，但同時(shí)也要應(yīng)對(duì)代碼編譯器產(chǎn)生的特殊 IIFE 閉包，防止對(duì)這種立即執(zhí)行閉包進(jìn)行重復(fù) parser。

最后，不要試圖總是將函數(shù)用括號(hào)括起來(lái)，因?yàn)檫@樣會(huì)導(dǎo)致惰性編譯的特性無(wú)法啟用。

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

如果你想?yún)⑴c討論，請(qǐng) 點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。前端精讀 - 幫你篩選靠譜的內(nèi)容。

關(guān)注 前端精讀微信公眾號(hào)

special Sponsors

• DevOps 全流程平臺(tái)

版權(quán)聲明：自由轉(zhuǎn)載-非商用-非衍生-保持署名（創(chuàng)意共享 3.0 許可證）

轉(zhuǎn)載于:https://www.cnblogs.com/ascoders/p/10752180.html

總結(jié)

以上是生活随笔為你收集整理的精读《V8 引擎 Lazy Parsing》的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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