Optimizing the Rust Compiler: September 2026 Update

By Nicholas Nethercote | Published September 30, 2026

It has been two months since my previous update on the Rust compiler's performance, and the landscape has shifted significantly in that time.

📈 Overall Progress

Between 2026-07-29 and 2026-09-28, we have seen a substantial leap in efficiency. The general trend is overwhelmingly positive.

Metric	Value
Mean Wall-Time Reduction	`4.57%`
Total Benchmarks	629
Improved Benchmarks	555
Regressed Benchmarks	74

Many specific benchmarks achieved double-digit percentage improvements.

🛠️ Tooling & Infrastructure Improvements

`rustdoc` & Clippy

rustdoc: As previously noted, Noah Lev secured massive speed gains. He has since published a detailed technical breakdown of his methodology.
Clippy: In PR #159642, Jakub Beránek implemented PGO (Profile Guided Optimization). This resulted in widespread wall-time improvements, peaking at 18% in the best scenarios.

LLVM Upgrade

Nikita Popov handled the transition to LLVM 23 in PR #158734. While a 1.2% mean wall-time reduction might seem modest, it is a significant win for a single PR.

🧠 The New Solvers

We are currently integrating two major architectural changes: a new borrow checker and a new trait solver.

Polonius Alpha (The New Borrow Checker)

Now active on Nightly, Polonius Alpha offers superior precision, allowing the compilation of valid programs that the legacy checker would reject. However, this precision comes with a computational cost.

To mitigate these regressions, Jack submitted the following:

#161938: Implemented lazy liveness computations, reducing instruction counts for serde by $3\text{--}5\%$ and others by $<1\%$ .
#163027: Optimized data structures and inlining, yielding sub-1% gains across various benchmarks.

"The 'sea of green' in our metrics indicates that these specific regressions are being drowned out by the broader wave of improvements."

Penelope Hammertime (The New Trait Solver)

Similar to Polonius, this solver is slower in a minority of instances. Jana Dönszelmann has documented the ongoing optimization efforts in a comprehensive post.

My own contributions include PRs #160479, #160605, #160801, #160892, #161077, and #161211. These targeted outlier crates, resulting in reductions of:

50% in some cases
25% in others
15% in others
Even higher gains on specific stress tests.

🚀 Contributions from xmakro

New contributor xmakro has provided a series of high-impact optimizations:

Specialization Graph: PR #157281 optimized impl handling, reducing mean cycle counts by 1.58%.
Incremental Compilation: PR #158059 improved data loading, cutting instruction counts by up to 6%.
Obligations Processing: PR #160473 eliminated allocations in a hot path, reducing instruction counts by up to 2%.
Solver Selection: PR #160268 replaced dynamic dispatch with static dispatch, reducing allocations.
- Note: I previously attempted this in #155714, but failed due to suboptimal #[inline] placement.

📉 Dataflow Analysis & CFG

I have focused on the efficiency of the compiler's dataflow analyses, which iterate until they reach a fixpoint.

CFG Traversal

In PR #160193, I overhauled the CFG traversal algorithm. This had a massive impact on the cranelift-codegen crate, which contains a function with $>18,000$ basic blocks.

Comparison for EverInitializedPlaces analysis: $\text{Old Algorithm: } 1,500,000 \text{ calls to } \texttt{apply\_effects\_in\_block}$ $\text{New Algorithm: } 90,000 \text{ calls to } \texttt{apply\_effects\_in\_block}$

This resulted in a ~30% wall-time reduction for check builds of that crate.

Projection Efficiency

PR #160033 optimized EverInitializedPlaces by stripping unnecessary projection data.

match-stress benchmark: $\downarrow 17\%$ instructions.
Other benchmarks: $\downarrow <1\%$ instructions.

📝 Final Notes & Miscellaneous

AI Assistance

I maintain full ownership of my code and text per project policy, but I did utilize LLM-based analysis to assist with several of the PRs mentioned above.

General Cleanup

Stack Size: Chris Denton (PR #160535) increased the default compiler stack size. This allowed us to remove ~~ensure_sufficient_stack~~, a manual mechanism used for deep recursion. This cut instruction counts by nearly 3% in some cases.
Rollup PRs: Due to CI constraints, we often use "rollup" PRs (merging multiple changes at once). While performance PRs are usually isolated for measurement, the sheer volume of improvements recently forced us to group them.

Current Status Checklist

Upgrade to LLVM 23
Enable PGO for Clippy
Fully eliminate Polonius Alpha regressions
Optimize Penelope Hammertime for all crates