How to speed up the Rust compiler in July 2026 | Nicholas Nethercote
My last<br>post<br>on the Rust compiler’s performance was in December 2025. Let’s see what has<br>happened since then.
Overall progress
The measurements for the period 2025-12-03 to 2026-07-29 can be seen<br>here.
The mean wall-time reduction was a healthy 5.59%. Around half of this was due<br>to some huge recent improvements in rustdoc, which saw a mean wall-time<br>reduction of 37.92%! With the rustdoc changes excluded,<br>the mean wall-time change was 2.90%, which is still a good result. There were<br>also some major improvements to the speed of Clippy, which isn’t currently<br>measured by rustc-perf on CI. (More about that below.)
rustdoc
#159623,<br>#159721,<br>#159779,<br>#159854: In these PRs, Noah<br>Lev greatly reduced the amount of work done when<br>processing impls. I won’t pretend to understand what he did in any more detail<br>than that (see<br>here<br>for some background) but I do know it resulted in many double- and single-digit<br>percentage reductions in wall-times. Guillaume Gomez<br>said “all of that<br>because someone encountered a weird bug when using rustdoc”.
#159091: In this PR Jakub<br>Beránek added rustdoc benchmarks to the<br>PGO training set,<br>which lets rustdoc benefit more from PGO. This gave a mean 2.85% reduction in<br>wall-time across all the rustdoc benchmarks, with the largest reduction<br>exceeding 6%. PGO is fiddly to set up but it can really make a difference,<br>and the training set matters.
#157179: In this PR I changed<br>the way rustdoc sorts impls. Previously it was sorting long generated HTML<br>strings containing impl names; now it uses a much shorter text representation<br>of the impl name as the sort key. This reduced instruction counts across<br>multiple benchmarks, in the best case by more than 6%.
The combined effect of these improvements can be seen in the following graph of<br>the relative wall-time of all the rustdoc benchmarks.
That’s a 28% reduction!
#2515: On a different<br>note, in this PR Jakub enabled rustdoc-json benchmarking on rustc-perf. This<br>will be helpful for the speed of tools that use rustdoc’s JSON output, such as<br>cargo-semver-checks.
Clippy
#17124,<br>#17132: In these two<br>PRs, xmakro made some huge speed-ups to Clippy.<br>Clippy consists of hundreds of separate lints, each of which can implement one<br>or more of a few dozen visitor methods: check_item, check_stmt, check_expr,<br>etc. Clippy traverses the AST and HIR and for each node it calls the<br>appropriate check_foo method for every lint on that node. Each call is a<br>virtual dispatch. Critically, most of these calls are no-ops because most lints<br>only implement a small number of check_foo methods (often just one). In these<br>PRs, xmakro found a way to combine the passes so that the empty check_foo<br>methods (i.e. the vast majority) are not called.
Around the same time I was investigating the exact same issue, and I came up<br>with a slightly different solution in<br>#157762. My solution was<br>functionally equivalent but the code changes were less elegant and more<br>invasive than xmakro’s. The PR didn’t merge, but I was able to get more<br>detailed<br>measurements:<br>in most cases this reduced Clippy’s runtime by 10-30%! Branch mispredictions<br>were reduced by 20-80% on real-world examples and by 97% on one stress test.<br>The cost of virtual dispatch adds up if you do it a lot.
Even though I’ve been working on Rust compiler performance for ten years, this<br>was the first time I tried to optimize Clippy. I found a major performance<br>problem and fixed it, only to find someone else had beaten me to it<br>by a few days. I’m not sad because the better solution was merged, but I am<br>still surprised—what are the chances of that?
Incremental compilation
We saw a number of minor improvements to incremental compilation.
#153122: In this PR<br>Zalathar improved how incremental compilation<br>promotes disk-cached values into memory, reducing instruction counts on many<br>benchmarks, in the best case by 6%.
#153521: This PR was another<br>tweak to incremental compilation by Zalathar, reducing instruction counts on<br>many benchmarks, in the best cases by more than 2%.
#154304: In this PR<br>zetanumbers adjusted how the typeck query<br>works, for instruction count reductions across multiple benchmarks, in the best<br>case by 6%.
#157781: In this PR xmakro<br>tweaked incremental compilation for instruction count reductions across many<br>benchmarks, in the best case by 5%.
#158794: In this PR xmakro<br>improved dep graph read deduplication for instruction count reductions across<br>multiple benchmarks, in the best case by 10%.
#159115: In this PR xmakro<br>again improved dep graph read deduplication for instruction count reductions<br>across many benchmarks, in the best case by 6%.
New trait solver
A lot of work is underway to get the new trait<br>solver<br>ready for release. This includes performance work. There is a lot going on and<br>I’m not aware of most of it, but this Zulip<br>thread<br>is a good place to read if you are interested in learning more or helping.
The following image shows the...