The Rust compiler got about four and a half percent faster across 629 benchmarks over the last two months

Opening a Rust project and waiting for the compiler is the slowest part of a lot of people's day. Nicholas Nethercote, who writes a public summary of Rust compiler performance work every couple of months, posted the September 2026 edition yesterday: the compiler is about 4.57 percent faster on average, measured across 629 benchmarks between late July and late September.

The post reached 198 points on Hacker News and the comments add context the headline number does not carry. A 4.57 percent mean hides much larger wins on specific crates, and specific crates are what a team actually waits for.

What the measurements say

The 629 benchmarks are the standard set run by the Rust compiler performance tracker. Nethercote reports 555 improving and 74 regressing over the two months. The post is a change log more than an essay: it credits contributors by name and links to pull request numbers.

A few of the larger single wins Nethercote lists: Nikita Popov's LLVM 23 upgrade in PR 158734 cut 1.2 percent off the mean across every benchmark. Jakub Beránek's PR 159642 added profile-guided optimisation to Clippy and bought back up to 18 percent of its wall time. Chris Denton's PR 160535 raised the main thread stack size and removed manual stack extensions, worth almost 3 percent of instructions. In the dataflow analysis, PR 160193 changed the control-flow graph traversal and cut about 30 percent off cranelift-codegen's wall time, and PR 160033 took 17 percent off a match-stress benchmark.

Where the double-digit wins came from

The two biggest sources of large single-crate speedups were the new trait solver and the new Polonius alpha borrow checker. Nethercote lists six of his own patches to the trait solver (PRs 160479, 160605, 160801, 160892, 161077, 161211) that between them took 50, 25 and 15 percent off three outlier crates. In Polonius, Jack Huey's PR 161938 made liveness computations lazy and cut Serde instruction counts by 3 to 5 percent, and PR 163027 made a data-structure change for mostly sub-1 percent reductions. A contributor named xmakro landed four PRs (157281, 158059, 160473, 160268) that together moved mean cycle counts by 1.58 percent and took up to 6 percent off a specific benchmark.

The consequence for a team on Rust

For a working team, two things follow. The first is that the slowest part of the day gets faster without anyone touching application code: upgrade past these commits and the test loop shortens on its own. The second is that the headline mean hides larger wins on specific crates, so the sensible move is to re-benchmark the slowest crate in the project after the toolchain upgrade. If that crate pulls on the trait solver, the new borrow checker or anything through LLVM's optimisation passes, the gain can easily be a multiple of 4.57 percent.

The HN discussion also notes an experimental metadata-emission approach that one commenter reports as "40 percent wall time speed up" on deeply nested projects such as rust-analyzer, though it still has integration problems around speculative compilation errors. That claim comes from an anonymous commenter rather than a landed pull request, so it is worth watching but not relying on. Nethercote's measured gains, by contrast, are already in the compiler for anyone running a current nightly.

Source

• Primary source: Nicholas Nethercote: How to speed up the Rust compiler in September 2026, 30 September 2026
• Discussion: Hacker News thread, 1 October 2026