11 月 25 日，Vue 發(fā)布了 3.3.9 版本，該版本除了解決了一些 Bug 之外，最重要的是對編譯器性能進行了優(yōu)化，使得編譯速度大幅提升，下面就來詳細看一下吧！

編譯器性能優(yōu)化

SFC 編譯速度整體提高 44%

基于使用 Elk 存儲庫中的所有 SFC 文件完成的基準(zhǔn)測試，這應(yīng)該在很大程度上代表了現(xiàn)實世界的應(yīng)用：

benching with:
- 225 files
- isProd: true
- sourceMap: true
- 3 warmup runs
- 10 bench runs

old compiler: 1513ms
new compiler: 845ms
new compiler is 44.15% faster.

---

benching with:
- 225 files
- isProd: true
- sourceMap: true
- 5 warmup runs
- 20 bench runs

old compiler: 2872ms
new compiler: 1618ms
new compiler is 43.66% faster.

注意：此基準(zhǔn)測試僅測量@vue/compiler-sfc解析 SFC 文件并將其轉(zhuǎn)換為JavaScript和 source map 所花費的時間。它不包括 CSS 處理、JavaScript打包和代碼壓縮。因此，對整個項目構(gòu)建時間的影響可能不會那么顯著，但仍然可以注意到。

解析速度提高 100%

解析器完全重寫，速度提高了100%。也就是說，與舊解析器相比，解析相同的模板它僅需要一半的時間。

舊解析器是一個遞歸下降解析器，使用了大量的正則表達式和低效的前瞻搜索。

新解析器使用了從htmlparser2 fork 出來的有限狀態(tài)機標(biāo)記器。它以線性方式迭代處理輸入，具有最小的前瞻和回溯，并且在很大程度上減少了對正則表達式的依賴。

代碼生成速度提高 40%

優(yōu)化了行/列計算

以前，每次調(diào)用CodegenContext.push都涉及迭代已推入的字符串，以檢查換行符，以記錄用于 source map 生成的正確行和列位置。分析表明，這個迭代在advancePositionWithMutation()中進行，導(dǎo)致了非常大的開銷。在本次優(yōu)化中，如果預(yù)先知道換行符的存在或位置，則可以跳過字符串迭代。

優(yōu)化了 source map 生成

SourceMapGenerator.addMapping花費了大量時間來規(guī)范化和驗證輸入?yún)?shù)。考慮到我們知道提供的是確切參數(shù)，可以通過直接添加映射來避免這個開銷。

消除SFC模板的雙重解析和 source map 開銷

與普通的Vue模板相比，SFC解析具有一些不同的要求：除<template>以外的所有根級標(biāo)簽的內(nèi)容應(yīng)被視為純文本，這是由于需要支持自定義塊。對于<template>仍然需要進行完整的標(biāo)簽結(jié)構(gòu)解析，因為內(nèi)部可能有嵌套的<template>標(biāo)簽，但是由于舊解析器選項的設(shè)計方式，生成的AST不能在模板編譯中重復(fù)使用。

這意味著對于每個SFC，我們需要執(zhí)行兩個解析調(diào)用：一個用于SFC塊，一個用于實際的模板內(nèi)容。此外，由于第二個模板解析是在已提取的內(nèi)容上執(zhí)行的，我們需要重新映射其 source map 位置，使其相對于整個SFC。這實際上非常昂貴，應(yīng)該避免。

新的解析器通過將SFC解析邏輯視為一級關(guān)注點來解決了這個問題。結(jié)果，可以直接重用<template>塊的AST進行后續(xù)的轉(zhuǎn)換和代碼生成，并且還可以避免昂貴的 source map 重新映射。

API 變更

重構(gòu)引入了對 AST 格式和@vue/compiler-core解析器選項的一些次要更改。這些屬性和選項主要在內(nèi)部使用，或者在自定義編譯器中使用（這些是非常高級的用例），因此它們不應(yīng)影響大多數(shù)最終用戶。

AST 格式更改

• 刪除屬性：ElementNode.selfClosingTag

除了舊解析器在解析階段使用該屬性外，該屬性從未在其他任何地方使用過，因此為了AST的簡潔性，已將其刪除。

解析器選項變更

• 新增選項：parseMode

類型：'base' | 'html' | 'sfc'

默認(rèn)值：'base'

為了最大化性能，處理HTML特定行為的一些邏輯（例如在<script>標(biāo)記內(nèi)部處理內(nèi)容）直接在標(biāo)簽生成器中處理。這種行為在默認(rèn)的'base'模式下被禁用。

在'sfc'模式下，除<template>以外的所有根級標(biāo)簽中的內(nèi)容都被視為純文本，而<template>的內(nèi)容則以'html'模式進行解析。

• 新增選項：ns

可以使用此新選項在解析模板時指定根名稱空間。

• 刪除選項：getTextMode

此選項的等效邏輯已經(jīng)硬編碼到標(biāo)簽生成器中，以獲得更好的性能。理論上，這確實消除了一些靈活性，因為無法定義應(yīng)視為純文本容器的替代標(biāo)記列表，但在實踐中并不存在這種用例。

大小增加

重構(gòu)導(dǎo)致運行時編譯器略微增大。全局構(gòu)建大小的變化，包括編譯器和運行時（min+brotli）：44.5kb => 46.4kb（+1.9kb）?？紤]到性能改進以及大小增加不會影響使用構(gòu)建步驟的項目，這是可以接受的。