Rust Builds Got 5.6% Faster. Read the Fine Print

Nicholas Nethercote's latest compiler-performance report card is out, and the headline number looks great: between early December 2025 and late July 2026, mean wall-time across rustc's benchmark suite dropped 5.59%. Then comes the fine print. Roughly half of that came from rustdoc, which got a staggering 37.92% faster. Strip rustdoc out and the compiler proper improved 2.90% over eight months.

Both numbers matter, but they tell different stories. One is about how much cheap performance was still lying around in the tooling that surrounds the compiler. The other is about how hard the core has become to speed up — and who, if anyone, is being paid to try.

Where the real speed landed

The rustdoc win is the kind of result that should make you go check your CI config today. Noah Lev landed a series of changes that slashed the work rustdoc does when processing trait impls — including one PR that stops building extern trait impls unless they're actually needed. Stacked with a fix that sorts impls by a short text key instead of comparing fully rendered HTML strings, the result was double-digit wall-time reductions across many benchmarks and that 37.92% mean.

If you build docs in CI, publish to docs.rs, or run cargo doc as part of a release pipeline, this is a free, large win the moment you update your toolchain. Doc builds have long been the ignored stepchild of Rust build performance — everyone profiles cargo build, almost nobody profiles cargo doc — and it turns out the neglect was expensive.

Clippy got a similar treatment. Most registered lints implement only a few of the many check methods the lint framework can call, but Clippy was still making virtual dispatch calls to piles of no-op default methods on every node. Eliminating those calls — a fix that also cut branch mispredictions by 20–80% on some benchmarks — reduced Clippy's runtime by 10–30%. For teams where cargo clippy is the slowest gate in CI (which is a lot of teams; Clippy does everything a cargo check does and then some), that's a real line-item saving.

The third standout is the new trait solver, where fixes for excessive memcpy traffic collapsed some pathological cases: one benchmark that took 27 seconds now finishes in under a second. The new solver has been shipping incrementally for a while — it's handled coherence checking since Rust 1.84 — and this is exactly the profile of work that had to happen before it can fully replace the old one. If you maintain the kind of generics-heavy crate where the type system occasionally goes nonlinear on you, these are your wins.

The grind inside the core

Now the other story. That 2.90% for the compiler proper wasn't one clever change; it was dozens of small ones. Shrinking AST expression nodes from 72 to 64 bytes (which cut cache misses enough to produce 10%+ wall-time wins on AST-heavy benchmarks). Deduplicating dependency-graph data in incremental compilation for a string of 5–10% improvements on individual benchmarks. Merging HIR queries. Removing single fields from AST nodes for sub-1% gains that only show up in aggregate.

This is what optimizing a mature, twenty-year-old-architecture codebase looks like: the flat parts of the curve, mined by hand. It's also the strongest argument for the most interesting project in the post — Krabby, arya dradjica's experimental from-scratch Rust compiler built to answer the question rustc can't easily answer about itself: how fast could a Rust compiler be if speed were the founding constraint? Krabby is explicitly a playground and a roadmap, not a rustc replacement — think research vehicle in the Servo tradition, where the point is to generate ideas the production system can absorb. Dradjica is currently focused on macro expansion and has already landed several small rustc improvements out of what she's learned.

Speed is a funding problem now

The most consequential line in the post isn't a benchmark. Nethercote — who has anchored Rust compiler performance work for nearly a decade, across the whole run of these reports — announced he's quit his job at VectorWare and is "pursuing opportunities to return to paid work on the Rust compiler." Meanwhile, dradjica's rustc time exists because NLnet Labs, working with RustNL, decided to donate one day a week of her employment to the project.

Read those two facts together. Rust compile times are the language's most-complained-about problem, cited in every survey, blamed for lost adoptions. And the labor that improves them is a handful of individuals sustained by whichever employer or nonprofit is currently willing to sponsor the work. When the single most prolific contributor in the space is between funding sources, that's not a personnel note — it's a statement about how fragile the pipeline behind that 5.59% actually is. The technical problem has an economics problem sitting on top of it, and the economics problem is currently the binding constraint.

What to do with this

Practically: update your toolchain and re-measure before touching anything else. Doc-building CI jobs and Clippy gates should get noticeably cheaper for free, and heavily generic crates may see their worst compile-time cliffs soften as trait-solver work continues. There's likely more coming from below, too — rustc-perf measurements of the in-progress LLVM 23 upgrade point to roughly another 2% mean improvement when it lands.

But don't mistake the trend for salvation. At ~3% per eight months in the core, rustc is not going to compile your workspace twice as fast any time soon. The usual self-help still dominates: cargo check in the inner loop, a fast linker, pruned features, split crates. What's changed is where to watch for step-changes — the periphery (rustdoc, Clippy, linkers, the trait solver) still has them, and clean-slate experiments like Krabby are where the next architectural ideas will come from. Whether anyone's funded to carry them home is, right now, the open question.