作者：林岚｜OC 开发者生态编辑

ast-grep 作者宣布用 Rust 重写 Tree-sitter 的 C 运行时核心。其基准显示，原始解析吞吐量提高约 29.7%，树遍历提高约 10%，完整 ast-grep outline 工作负载的用户态 CPU 时间下降约 22.2%。

一句话结论：这不是 Rust 原样替换 C 后自动变快，而是针对 Agent 的整文件分析场景删掉功能、重做内存布局，并在多次失败后得到的窄化实现。

新运行时保持现有生成语法、外部扫描器和 C ABI 兼容，但不再支持原生加载 WebAssembly 语法，也移除了增量旧树复用。这个取舍对编辑器很重要：编辑器需要每次按键后复用旧语法树，而 ast-grep 和代码 Agent 更常处理完整文件快照。

作者让 ChatGPT 完成了大量移植、分析和实验代码。早期版本虽然局部快了 20%，却难以理解并出现段错误，最终被全部回退。后续过程改为一次只优化一个机制，并同时检查解析、树遍历、内存和完整应用。

关键优化包括：普通输入先使用线性栈，遇到真正歧义时再建立图结构；用 arena 降低节点分配成本；缩小索引；避免重复读取子节点。这里没有一个“换语言”魔法开关，真正收益来自缩小目标和改变数据结构。

内存是明确代价。完整 outline 测试中，Rust 版本峰值约 34.43MiB，C 版本约 26.52MiB，多出接近 8MiB。更早的 arena 方案还曾让大型 TypeScript 测试峰值超过 1GiB，修正后才降到 91.2MiB。

因此标题中的 30% 只对应解析器吞吐，不是所有 Tree-sitter 用户都能获得的升级幅度。需要增量解析、原生 Wasm 语法或极低内存的工具，不能直接套用结论。

关键事实

• 原始解析吞吐：约提升 29.7%
• ast-grep 完整工作负载：用户态 CPU 时间约下降 22.2%
• 内存变化：完整测试峰值增加约 8MiB
• 功能边界：移除增量旧树复用和原生 Wasm 语法加载
• 开发方式：AI 生成大量代码，人类负责约束、分析和验收

OC 判断

这个项目说明 AI 能让个人尝试过去不敢启动的大型重写，也说明生成速度会放大错误优化。最终成果来自严格缩小使用场景和端到端验证，而不是“Rust + AI”两个标签。

为什么重要

• 对开发者：性能基准必须覆盖真实生命周期，不能只测最内层循环。
• 对 Agent 工具：整文件分析和编辑器增量解析可能需要不同运行时。
• 对维护者：AI 重写仍需要可理解的架构、回退能力和兼容测试。

参考来源

• ast-grep：How we rewrote Tree-sitter in Rust and made it 30% faster
• GitHub：ast-grep/ast-grep
• GitHub：HerringtonDarkholme/tree-sitter