第1部分共4部分——完整的冒险ast-grep在Rust中重写了Tree-sitter的C核心，AI编写了代码。新的核心在解析方面更快，在读取完成的树时更快，在ast-grep本身运行时更快。（标题中的“30%”是仅指解析器的改进；从端到端计算，ast-grep大约快22%）源代码库：HerringtonDarkholme/tree-sitter。在介绍数字之前，先简单介绍一下。ast-grep——本博客所属的结构化代码搜索工具——按语法而非文本搜索代码，因此它所接触的每个文件必须首先变成语法树。Tree-sitter是构建该树的解析框架：你给它一个语法定义，它会为该语言生成一个快速的解析器。出生于编辑器世界，现在它驱动着巨大的语法和工具生态系统。性能和峰值RSS。通过量化，未修改的C构建（“C / normal”）得分为100；得分越高越好。RSS是峰值常驻内存，原始解析行将其显示为一个范围，因为它在基准的语言固定装置中有所变化。大纲行是ast-grep的真实工作负载：解析存储库中的每个文件，然后遍历每棵完成的树以提取结构大纲。基准 C / normal Rust 差异 原始解析 吞吐量：100 RSS：8.48–21.41 MiB 吞吐量：129.74 RSS：8.42–25.70 MiB +29.74% 吞吐量 +20.0% RSS 上限 树遍历 吞吐量：100 RSS：20.38 MiB 吞吐量：110.16 RSS：22.20 MiB +10.16% 吞吐量 +8.9% RSS 完整的ast-grep大纲 用户CPU：1.233 s RSS：26.52 MiB 用户CPU：0.960 s RSS：34.43 MiB −22.2% 用户CPU +29.8% RSS Rust在每个解析器和遍历固定装置中获胜，且ast-grep生成了完全相同的大纲。内存是权衡：Rust构建在ast-grep运行中使用约8 MiB更多的内存。在更大的TypeScript压力语料库——TypeScript编译器存储库的测试基线树，这个项目的内存压力测试——它的峰值达到91.2 MiB。这个数字是一个胜利，而不是一个忏悔：在项目初期，相同的语料库的峰值超过1 GiB。这个结果并不是上游Tree-sitter的1:1替代品。它是一个为分析完整文件快照而构建的较窄的运行时：现有的生成语言和解析器仍然兼容。WebAssembly编译语言的本地加载和增量旧树重用已被移除。兼容性仍然需要许多原始指针和不安全块。这个边界使语法生态系统对智能编码保持有用，同时移除目标工作负载不需要的编辑器特定机制。故事到此结束。到达那里是另一回事。为什么重写Tree-sitter？每一个严肃的ast-grep性能调查最终都到达了同一个地方：Tree-sitter。ast-grep可以使其规则更快。它可以修剪工作，缓存配置，避免访问无关的语法。但是每个文件仍然需要首先成为语法树，而Tree-sitter构建了那棵树。解析器既是基础，也越来越成为上限。我多年来一直梦想重写或深度优化它。这个梦想通常持续到我打开运行时。它有一个成熟的C实现，二进制兼容性，外部扫描器，错误恢复，增量解析，歧义语法，几个语言绑定，和一个小问题，即不破坏构建在这一切之上的巨大语法生态系统。对于一个人来说，这并不是一个周末项目。这是一项穿着头文件的海克力士任务。因此没有变化。然后，AI辅助的重写尝试开始在各处出现—Bun，pgrust和Roc等。它们没有证明重写Tree-sitter是明智的，没有使运行时更小，也没有使解析器理论变得不那么奇怪。它们表明，这个实验已变得足够便宜，可以让一个人尝试，从而给予我足够的杠杆去提出不合理的问题，并在这十年结束前得到回答。因此，我指示ChatGPT将Tree-sitter的C核心重写为Rust。该项目从兼容性优先的翻译，经过快速但不可读的优化尝试，迈向更简单的运行时和真正的解析器收益——最终发现更快的解析器仍然可能使ast-grep变慢。这篇文章的其余部分将记录这个旅程：什么有效，什么不得不被撤回，以及将解析器基准的胜利转化为应用胜利所需的努力。Tree-sitter的解析架构Tree-sitter接受源代码并生成一个语法树。每种支持的语言开始于Tree-sitter编译成生成的解析表和词法分析器代码的语法定义；当这一系列说“生成的语言”，“生成的语法”或“生成的表”时，它指的是这些工件。在运行时，词法分析器将字符转换为标记，如标识符、+和数字。然后，解析器使用生成的表和堆栈来决定每个标记的含义。大多数情况下，表请求两种操作之一：推送：消费一个标记并将其推入解析器堆栈；规约：识别多个组合的结构。