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

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

SFC 編譯速度整體提高 44%

基于使用 Elk 存儲(chǔ)庫(kù)中的所有 SFC 文件完成的基準(zhǔn)測(cè)試，這應(yīng)該在很大程度上代表了現(xiàn)實(shí)世界的應(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)測(cè)試僅測(cè)量@vue/compiler-sfc解析 SFC 文件并將其轉(zhuǎn)換為JavaScript和 source map 所花費(fèi)的時(shí)間。它不包括 CSS 處理、JavaScript打包和代碼壓縮。因此，對(duì)整個(gè)項(xiàng)目構(gòu)建時(shí)間的影響可能不會(huì)那么顯著，但仍然可以注意到。

解析速度提高 100%

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

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

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

代碼生成速度提高 40%

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

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

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

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

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

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

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

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

API 變更

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

AST 格式更改

• 刪除屬性：ElementNode.selfClosingTag

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

解析器選項(xiàng)變更

• 新增選項(xiàng)：parseMode

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

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

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

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

• 新增選項(xiàng)：ns

可以使用此新選項(xiàng)在解析模板時(shí)指定根名稱空間。

• 刪除選項(xiàng)：getTextMode

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

大小增加

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