如何在2026年9月加速Rust编译器

# 如何在2026年9月加速Rust编译器 来源：https://nnethercote.github.io/2026/09/30/how-to-speed-up-the-rust-compiler-in-september-2026.html 我上一篇关于Rust编译器性能的文章（https://nnethercote.github.io/2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html）发表于两个月前，此后发生了很多事。 ## 整体进展 2026-07-29至2026-09-28期间的测量数据可在此处查看（https://perf.rust-lang.org/compare.html?start=1a833e16546c2eb012758ddd499964fd8afee29e&stat=wall-time&tab=compile&end=c1070d69382b8d2f2eb65119c738a77d9e324c9e&nonRelevant=true）。 平均运行时间减少4.57%，这是两个月内取得的显著进步。在629项基准测试中，555项有所改善，仅74项出现退步。多项基准测试的降幅达到两位数百分比。这一结果的技术术语是“一片绿色的海洋”。 ## rustdoc 在我上一篇文章中提到Noah Lev（https://github.com/camelid）在rustdoc方面取得了巨大速度提升。他最近撰写了一篇博文（https://noahlev.org/blog/2026/08/27/making-rustdoc-faster），详细解释了具体实现方法。这篇文章读起来既有趣又令人满足。 ## Clippy \#159642（https://github.com/rust-lang/rust/pull/159642）：在该PR中Jakub Beránek（https://github.com/Kobzol）为Clippy启用了PGO，使大多数Clippy基准测试的运行时间得到改善，最佳情况下提升18%！ ## LLVM更新 \#158734（https://github.com/rust-lang/rust/pull/158734）：在该PR中Nikita Popov（https://github.com/nikic）将编译器使用的LLVM版本升级至LLVM 23。正如升级LLVM时常发生的那样，我们观察到了一些不错的速度提升。所有基准测试的平均运行时间减少1.2%，虽然听起来不多，但对于单个PR来说确实令人印象深刻。LLVM团队工作出色！ ## 新的借用检查器 新的借用检查器Polonius（https://en.wikipedia.org/wiki/Polonius）Alpha（https://en.wikipedia.org/wiki/Alpha）（与Napoleon Dynamite（https://www.youtube.com/watch?v=gdZLi9oWNZg）无关）已在Nightly版本启用（https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-nightly/）。它比现有借用检查器更精确，能接受一些旧检查器会拒绝的有效程序。它确实比旧检查器完成更多工作，在少数情况下对编译时间产生可测量的影响，包括流行的`serde`crate。幸运的是，Jack Huey（https://github.com/jackh726）一直在处理这个问题。 \#161938（https://github.com/rust-lang/rust/pull/161938）：在该PR中Jack将部分活跃性计算设为惰性执行，使`serde`的指令数减少3-5%，其他基准测试的降幅小于1%。 \#163027（https://github.com/rust-lang/rust/pull/163027）：在该PR中Jack调整了数据结构并优化了内联策略，使众多基准测试的指令数降幅大多低于1%。 还有更多工作待完成以减少Polonius Alpha剩余的退步，但值得注意的是，“绿色的海洋”表明这些退步被近期的众多其他改进所淹没。 ## 新的特征求解器 新的特征求解器Penelope（https://en.wikipedia.org/wiki/Anne_Hathaway）Hammertime（https://www.youtube.com/watch?v=q8WSdypJ4WA）*[编注：正确吗？]*也在Nightly版本启用（https://blog.rust-lang.org/2026/08/21/enabling-next-solver-on-nightly/）。 正如我所说，发生了很多事情。 与新的借用检查器类似，新的特征求解器在少数情况下更慢。Jana Dönszelmann（https://github.com/jdonszelmann）撰写了一篇详细博文（https://donsz.nl/blog/new-solver-performance），介绍改进这个新求解器性能所做的努力。 Jana的文章足够详细，我不会再赘述关于新求解器的大量进行中的工作，但我会顺带提及我提交的PR：\#160479（https://github.com/rust-lang/rust/pull/160479）、\#160605（https://github.com/rust-lang/rust/pull/160605）、\#160801（https://github.com/rust-lang/rust/pull/160801）、\#160892（https://github.com/rust-lang/rust/pull/160892）、\#161077（https://github.com/rust-lang/rust/pull/161077）和\#161211（https://github.com/rust-lang/rust/pull/161211）。其中一些PR大幅减少了特定异常crate的编译时间：这里50%，那里25%，那里15%，甚至在一个压力测试中减少更多（https://github.com/rust-lang/rust/issues/159933#issuecomment-5333109889）。而我并不是唯一取得进展的人...请阅读Jana的文章。 ## xmakro 新贡献者xmakro（https://github.com/xmakro）持续贡献优秀的改进。 \#157281（https://github.com/rust-lang/rust/pull/157281）：在该PR中xmakro优化了构建特化图时的impl处理。这使所有基准测试的平均周期数减少1.58%，对于单个PR来说是巨大的进步。 \#158059（https://github.com/rust-lang/rust/pull/158059）：在该PR中xmakro优化了增量编译数据加载的一个方面，减少了多项基准测试的指令数，最佳情况下降低6%。 \#160473（https://github.com/rust-lang/rust/pull/160473）：在该PR中xmakro通过避免热义务处理路径中的一些分配，减少了众多基准测试的指令数，最佳情况下降低2%。 \#160268（https://github.com/rust-lang/rust/pull/160268）：在该PR中xmakro通过将旧/新特征求解器选择代码改为使用静态分派而非动态分派，避免了大量分配。这使多项基准测试的指令数降幅大多低于1%。这个热分配路径在性能分析中已显现一段时间，我早前在\#155714（https://github.com/rust-lang/rust/pull/155714）中尝试过完全相同的想法。但我在几个基准测试中出现了退步，可能是由于放置某些`\#[inline]`属性的选择略有不同。看到这个明显的低效问题被修复是件好事。 ## 数据流分析 \#160193（https://github.com/rust-lang/rust/pull/160193）：在该PR中我更改了编译器中数据流分析使用的CFG遍历算法。这些分析通过迭代达到不动点，遍历算法会影响达到不动点的速度。对于大多数代码，新算法没有区别，但`cranelift-codegen`crate有一个包含超过18,000个基本块的巨大函数。旧算法需要150万次调用`apply_effects_in_block`才能为借用检查器使用的`EverInitializedPlaces`分析达到不动点；新算法仅需90,000次。这为该crate的`check`构建带来了约30%的巨大运行时间减少。 \#160033（https://github.com/rust-lang/rust/pull/160033）：在该PR中我再次提高了`EverInitializedPlaces`的效率，这次是通过不为投影跟踪不必要的数据。这使`match-stress`基准测试的指令数减少17%，其他几个基准测试的降幅小于1%。 ## 大语言模型 它们在某些分析任务上变得非常出色。我仍然自己编写所有代码和文本，因为（a）这至关重要，且（b）项目策略（https://forge.rust-lang.org/policies/llm-usage.html）要求如此，但在本文提到的几个PR中，我获得了有用的大语言模型分析辅助。 总之，就此打住。 ## 杂项 \#160535（https://github.com/rust-lang/rust/pull/160535）：在该PR中Chris Denton（https://github.com/ChrisDenton）增加了编译器使用的默认栈大小，从而允许移除`ensure_sufficient_stack`——这是一个散布在容易出现高递归级别位置的手动栈扩展机制。关于这个PR有很多讨论，因为如何最佳处理栈耗尽可能很难决定。但性能影响是明确的，使众多基准测试的指令数减少，最佳情况下降低近3%。 \#160506（https://github.com/rust-lang/rust/pull/160506）：项目使用大量“rollup”PR，将多个PR合并在一起。这是因为我们没有足够的CI容量来单独合并每个PR。通常影响性能的PR会单独合并，以便我们清晰测量其效果。有史以来第一次，我们一度有如此多的性能改进PR在合并队列中等待，以至于Jonathan Brouwer（https://github.com/JonathanBrouwer）创建了一个包含10个性能改进PR的rollup以保持进度！这是个幸福的烦恼。后来我们有了\#162859（https://github.com/rust-lang/rust/pull/162859），包含四个性能改进PR。（你不必担心意外影响混入，因为我们在合并后能够对各个PR运行性能基准测试套件，以确保每个PR都产生了预期的性能效果。） \#162747（https://github.com/rust-lang/rust/pull/162747）：在该PR中我对将AST降级为HIR的代码进行了一些小改进。这本是一次不期望影响性能的清理工作，却使众多基准测试的指令数减少，最佳情况下降低1.5%。有时运气就是这么好。 ## 职位状态 明天我将开始在Hexcat（https://hexcat.nl/）从事编译器性能优化（https://goals.rust-lang.org/2026/compiler-performance-optimization.html）项目目标的工作。这很令人兴奋！衷心感谢Mara Bos、Predrag Gruevski以及所有其他帮助实现这一目标的人。 ### *编者注* 新求解器的名称不是Penelope（https://en.wikipedia.org/wiki/Penelope,_Texas）Hammer（https://www.youtube.com/watch?v=OJWJE0x7T4Q）time（https://www.youtube.com/watch?v=Qr0-7Ds79zo）；那是个玩笑。 其真名是Pineapple（https://en.wikipedia.org/wiki/Australian_fifty-dollar_note）Häagen-Dazs（https://en.wikipedia.org/wiki/Ben_&_Jerry's）。