语法高亮本身不拖慢编辑器，但TextMate词法解析（tokenize）在长行、深嵌套或正则回溯失控时会阻塞UI线程，导致卡顿；需用Process Explorer和Performance面板定位tokenization热点，禁用语法关联或运行benchmark.js量化性能。
语法高亮本身不直接拖慢编辑器，但 TextMate 词法解析（tokenize）在特定文件上可能成为性能瓶颈——尤其是长行、深嵌套、大量字符串或正则回溯失控时。检测它是否在拖慢你，关键不是“看有没有高亮”，而是“看 tokenize 是否卡住主线程”。
用 Developer: Open Process Explorer 实时观察 tokenization 负载
VSCode 的语法高亮由 Monaco 编辑器在渲染进程里执行，tokenize 是同步操作，会阻塞 UI 线程。当打开一个大文件（如 .tmTheme、压缩 JS、超长 JSON）后卡顿，大概率是这里出问题。
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入并执行Developer: Open Process Explorer - 重点关注 Renderer 进程的 CPU 占用：如果持续 >70%，且对应文件刚被打开，基本可锁定是 tokenization 压力
- 右键该进程 →
Take Heap Snapshot或Start Tracing，导出后用speedscope查看热点函数是否集中在TextMateTokenizationSupport.tokenize或Oniguruma.search
用 Performance 面板抓取 tokenization 具体耗时
Monaco 默认对单行 tokenization 设有长度限制（editor.maxTokenizationLineLength，默认 20000），但超长行仍会触发多次正则尝试，导致毫秒级延迟累积成明显卡顿。
- 打开目标文件（如一个含 base64 字符串的
.tmTheme） -
Ctrl+Shift+P→Developer: Toggle Developer Tools→ 切到Performancetab - 点击录制 → 滚动几屏 → 停止 → 筛选
tokenize或highlight - 你会看到类似
TextMateTokenizationSupport._tokenizeString的调用栈，展开后能看到单次调用耗时（常达 5–50ms/行）
关掉高亮验证是不是真凶
禁用语法高亮只是表象，真正要切的是语言服务和 tokenization 引擎。单纯换语言模式为 plaintext 不够，因为某些扩展仍后台加载语法定义。
- 右下角点击当前语言标识（如
XML）→Configure File Association for '.tmTheme'→ 输入plaintext（注意不是 “Plain Text”）并回车 - 检查
settings.json中是否已写入："files.associations": { "*.tmTheme": "plaintext" } - 重启 VSCode 后再打开同一文件，对比 Process Explorer 中 Renderer 进程 CPU 是否骤降（通常下降 60%+）
- 若仍有卡顿，说明问题不在高亮，而在文件监视（
fileWatcher）或扩展本身（比如 XML 验证器仍在跑）
用 benchmark.js 复现并量化 tokenize 性能
如果你在开发或调试自定义 TextMate 语法（.tmLanguage），vscode-textmate 自带的基准测试脚本是最准的度量工具——它绕过 VSCode，直测引擎本身。
- 克隆仓库：
git clone https://github.com/microsoft/vscode-textmate - 运行：
npm install && npm run compile && npm run benchmark - 输出中关注
TOKENIZING XXX lines using grammar XXX后的Oniguruma: YYY ms—— 这就是纯 tokenize 耗时 - 对比不同 grammar 下同一文件的
ms/line：若你的语法比source.js高出 3 倍以上，说明正则设计存在回溯风险（比如(a+)+b类模式）
真正容易被忽略的点是：tokenization 卡顿往往只在首次打开或滚动到未缓存区域时发生；一旦 token 已缓存，后续滚动就快得多。所以检测必须在“冷启动状态”下做，而不是反复 reload 窗口——那测的是缓存命中率，不是真实 tokenize 成本。
