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

編譯器性能優化

SFC 編譯速度整體提高 44%

基于使用 Elk 存儲庫中的所有 SFC 文件完成的基準測試，這應該在很大程度上代表了現實世界的應用：

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.

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

解析速度提高 100%

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

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

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

代碼生成速度提高 40%

優化了行/列計算

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

優化了 source map 生成

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

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

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

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

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

API 變更

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

AST 格式更改

• 刪除屬性：ElementNode.selfClosingTag

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

解析器選項變更

• 新增選項：parseMode

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

默認值：'base'

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

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

• 新增選項：ns

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

• 刪除選項：getTextMode

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

大小增加

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