Vue 又更新了，性能大幅提升！-51CTO.COM

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）。考虑到性能改进以及大小增加不会影响使用构建步骤的项目，这是可以接受的。