Vize
表演调校
前端工具链的性能调优不仅仅是一个技巧。
这不是“用Rust重写”然后等图表出来。这是一连串细微而具体的决策，比如时间流向、内存移动频率、重复工作量以及架构是否允许改进叠加。
这条笔记是 Vize 不断优化的知识分享。
测量整个循环
编译器基准测试有用，但它们并不是开发者的全部体验。
Vue工具链有多个反馈回路：
开发服务器中的单文件编译
完整量产版本
对多个文件进行线条处理
格式化大量文件
类型检查生成的虚拟文件
用户输入时进行编辑器诊断
跨实际应用的配置项检查
AI生成的补丁被反复验证
最慢的循环并不总是最明显的。
一个单独看起来很快的功能，如果在每个阶段都运行，仍然可能有害。如果分配量很少，但如果对每个令牌、每个AST节点、每个诊断和每个生成的段都发生，仍然可能有影响。
这就是为什么 Vize 把性能视为工具链属性，而不仅仅是编译器属性。
避免重复工作
最可靠的优化是不要重复做同样的工作。
在分段设置中，同一.vue文件可以通过以下方式单独解析：
编译器
吊坠
格式化器
类型检查器
编辑器集成
组件文档流程
这很贵，但更深层的问题是架构层面。如果每个工具都建立自己对文件的理解，性能调优就会变得局部且有限。
Vize围绕共享结构设计：
可能的话只解析一次
保持SFC区块边界稳定
在编译器和诊断之间重复使用模板结构
让语义分析为多个消费者提供信息
除非输入发生变化，否则避免重新生成虚拟 TypeScript
最好的优化往往是更好的所有权边界。
分配是特征，不是细节
前端工具处理许多小对象：令牌、节点、跨度、字符串、作用域、诊断、生成的代码片段。
如果这些对象是随意分配的，工具链会在各处支付费用。
Vize对分配行为施加了很大压力：
用于短寿命编译器数据的竞技场式存储
字符串内部处理，重复标识符或名称很重要
紧缩的张成代替复制的子串
借用片，所有权不必要
稳定的内部ID代替大型克隆结构
目标不是为了代码本身而巧妙。
目标是让热路径变得无聊：减少分配、更少的副本、更少的缓存未命中、减少分配者成为配置文件一部分的理由。
平行性需要形态
并行不是“打开线程”。
当问题有明确的界限时，它效果最佳：
许多独立文件
确定性聚合
可预测的输出排序
无共享全局突变
有界缓存和会话
Vue编译、linting和夹具扫描通常具有自然的文件级并行形状。但字体检查和编辑工作流程更为微妙，因为它们依赖于项目状态。
因此，Vize将问题分开：
这些文件级工作能否独立运行？
这一步需要驻地项目会议吗？
输出顺序是否对用户可见？
诊断在不同线程计数间是否稳定？
并行性是否会增加足够的内存压力以消除胜利？
快速但不稳定的输出是不够好的。表演工作必须维护信任。
源映射可能成为热门路径
Vue工具通常生成中间代码。
这意味着每一次良好的诊断都需要一条回归的路径：
生成TypeScript到原始模板
生成的渲染代码转为SFC源代码
将样式或脚本输出转换为原始块
虚拟模块ID回返回真实文件
如果源映射缓慢或不精确，整个工具链都会受到影响。用户在错误的地方看到了诊断信息。AI修复循环的坐标很差。测试变得脆弱。
因此，源映射应与解析同等重视性能：
存储紧缩跨度
避免重复路径归一化
保持生成的段元数据较小
通过快照测试边缘案例
分析性强的诊断负载，而不仅仅是成功的编译路径
诊断是产品表面。他们的表现很重要。
真实项目胜过合成舒适
微基准测试在回答重点问题时非常有用。
但当工具链与真实项目对比时，它才变得诚实。
真实项目包括：
奇数依赖布局
大型SFC
遗留模式
自动生成代码
非常规指令
插件约定
路径别名
平台特定的边缘情况
这就是为什么Vize持续投资于真实世界的赛程扫描和建筑快照。目标不是收集令人印象深刻的测试数量。目标是揭示那些只有在代码混乱时才会出现的性能悬崖，就像生产代码那样混乱。
性能是产品特性
速度改变了行为。
如果检查很慢，人们就会减少运行频率。 如果格式化慢，保存格式就会变得烦人。 如果类型识别的填充速度较慢，团队会禁用规则。 如果CI慢，维护者会批处理变更和审查。 如果AI验证缓慢，代理会做出更大、更冒险的飞跃。
快速工具使得更严格的工作流程变得实用。
这才是Vize性能的真正理由。目标不仅仅是一个更好的基准数字。目标是让严格的路径感觉像默认路径。
当编译、除絮、格式化、类型检查和诊断都足够快，无需繁琐地运行时，质量就不再是一件特别的事了。
这成为了正常的工作方式。