两个月时间,测试套件里 629 个基准有 555 项飘绿,挂钟时间平均缩短 4.57%。在编译器这种锱铢必较的底层工程里,这个战报好看得像某种大干快上的宣发通稿。

但如果你正维护一个重度依赖宏和复杂泛型的项目,千万别急着开香槟。这份看似全线飘绿的成绩单,底色并不是新架构顺理成章的效率红利,而是一场惊险的对冲战。

Rust 编译器 2026 秋季性能战报盘点 -4.57% 平均挂钟时间缩短 555 / 629 性能改善基准数量 -1.2% 升级 LLVM 23 全局收益 -18% Clippy PGO 最佳提速

绿屏之下的性能通胀

要看懂这次性能提速的真实成色,得先看 Rust 官方团队在 2026 年 8 月干了两件什么事。

他们先后在 Nightly 分支上默认启用了两套重构数年的核心基建:8 月 4 日上线的 Polonius Alpha 借用检查器,以及 8 月 21 日上线的 Next-generation trait solver(新一代 Trait 求解器)。

这两套系统解决的是 Rust 语言层面的心腹大患。旧的借用检查器规则粗糙,经常误杀完全合法的代码;旧的求解器则残留着不少类型系统的健全性漏洞,甚至锁死了类型别名隐式特征(TAIT)和返回位置特征约束(RTN)等长期演进。换掉它们不是为了变快,而是为了严密。

严密必然伴随计算复杂度的陡增。

新求解器在 top 20,000 个 crates 库测试中,大部分性能相近,但分化极其悬殊。对于 DataFusion 这类重型项目,编译时间大幅提速超 8 倍,连国际象棋类型系统压力测试也从旧版的超时挂起缩短到约 1 分钟;但在极少数边缘场景下,算法复杂度会猛烈膨胀成二次方甚至指数级耗时。

而在主流库上,代价更为直接:著名的 serde 在 Polonius Alpha 启用后出现肉眼可见的编译回退。8 月 24 日的官方测试显示,在未训练针对性 PGO 的快照下,主基准平均回退了约 0.6%。

前端架构换血带来的性能债务,如果放任不管,足以吃掉开发者数月来的优化积蓄。

前后端分工:为什么后端救不了类型推导 前端开销(本轮风暴核心) • 核心模块:Polonius Alpha / 新 Trait 求解器 • 职责:语法解析、生命周期推导、健全性校验 • 特征:与代码生成正交,换后端毫无作用 后端生成(工程收益承托) • 核心模块:LLVM 23 / 机器码生成 / 链接 • 职责:LLVM 升级贡献 1.2% 全局提速 • 现状:GCC 实验后端目前整体明显慢于 LLVM

战壕里的微观对冲

既然核心架构为了正确性引入了高额开销,这 4.57% 的大盘提速究竟从哪抠出来的?答案是:编译器工程师打了一场极其凶残的微观消耗战。

他们先借助外部引擎托底。8 月 5 日,PR #158734 将编译器内置后端升级至 LLVM 23,处理了 Windows f128 ABI 与 Darwin 动态库优化,单挑出一个 PR 就拿到了全基准平均 1.2% 的挂钟缩短。随后 8 月 21 日合并的 PR #159642 为 Clippy 启用了配置文件引导优化(PGO),让 79 个主要基准指令数下降约 5%,部分基准挂钟时间缩短高达 18%。

但在编译器前端内部,争夺是以指令数和内存分配为单位计算的:

  • 针对借用检查器的惰性化修剪.面对 serde 编译暴跌的问题,工程师通过 PR #161938 将 Polonius 的活跃度分析改为惰性计算,硬生生把 serde 的指令数扳回 3-5%;紧接着 PR #163027 调整了约束数据结构与内联策略,让 17 个主基准平均再降 0.4%,且不出现任何主基准回退。
  • 高频调用路径的静态分发重写.针对新老求解器并存带来的性能损耗,贡献者在 PR #160268 中用静态分发替换了运行时的动态分发,抹去了热路径上频繁的堆内存分配。
  • 数据流分析的图遍历算法换代.控制流图遍历算法的迭代直接影响收敛到不动点的耗时。对于 cranelift-codegen 这种包含 18,000 个基本块的巨型函数,新算法让状态计算调用从 150 万次骤降到 9 万次,直接砍掉近 30% 的 check 编译耗时。

这场战役之所以壮观,是因为它几乎全是由细碎的工程手术堆出来的。甚至一度因为等待测试验证的优化代码过多,官方不得不在合并队列中破例打包合并了十多个 PR。最终,正是这些漫山遍野的局部微调,硬生生把新基建带来的回退给“吃”了下去。


换后端救不了前端的账

社区里长期存在一种迷思:既然 Rust 编译慢,换个更轻量或基于 GCC 的后端不就解脱了?

这种预期完全错配了编译器管线。编译耗时由前端(类型推断、Trait 解析、生命周期分析)与后端(优化、机器码生成)共同主导。借用检查与求解器在进入后端优化前就早已执行完毕,它们引起的计算膨胀是纯粹的前端问题,与 LLVM 还是 GCC 毫无瓜葛。

更何况在现实工业界中,实验性的 GCC 后端(如 rustc_codegen_gcc)当前的编译耗时依然明显落后于打磨数十年的 LLVM。寄希望于更换后端来规避前端类型系统重构的代价,属于缘木求鱼。

  • 风险.如果一个团队正考虑把 Nightly 上的新借用检查器与新 Trait 求解器过早用于核心业务生产流水线,很可能会遭遇严重分化的编译耗时抖动,部分重度宏项目甚至面临长尾卡顿。

Rust 官方在 2026-2027 编译器性能目标里立下过一条硬性红线:新 Trait 求解器与 Polonius 必须达到与旧系统平齐的性能平价,否则绝不允许进入稳定版。

求木之长者,必固其根本。4.57% 的提速不是这场重构的终点,而是拉锯战打响的号角。用外围性能补贴核心开销的手法只可解一时之急,新架构唯有在真实项目里彻底抹平计算复杂度的长尾回退,这场声势浩大的基建换血才算真正落定。