Rust compiler speed wins from July 2026

5.59% mean wall-time reduction shows where July 2026 Rust compiler work paid off.

This guide is for Rust compiler contributors, performance engineers, and tool authors who want a practical read on the latest speed work in rustc, rustdoc, Clippy, and incremental compilation. After you follow the steps, you will know how to reproduce the measurements, inspect the biggest wins, and spot the kinds of changes that moved wall time by double digits.

Before you start

• A Linux or macOS machine with Rust nightly installed.
• Rust 1.87+ or a recent nightly toolchain for building rustc.
• Python 3.10+ for scripts and result inspection.
• Git installed and access to the Rust compiler repository.
• rustc-perf checkout, plus permission to run long benchmark jobs.
• Valgrind tools installed if you want Cachegrind and DHAT profiling.
• Access to the rustdoc and Clippy performance benchmark data mentioned in the source article.

Step 1: Clone the benchmark repos

Your first outcome is a local workspace that can build compiler changes and compare them against performance baselines. The source article discusses rustc-perf measurements, rustdoc benchmarks, and profiling runs, so you need both the compiler and the benchmark harness available.

git clone https://github.com/rust-lang/rust.git
git clone https://github.com/rust-lang/rustc-perf.git
cd rust
rustup toolchain install nightly
rustup default nightly

You should see both repositories on disk and a working nightly toolchain when you run rustc --version.

Step 2: Run a baseline benchmark suite

The goal here is to capture a before snapshot so later changes have a clear comparison point. The article’s headline result, 5.59% mean wall-time reduction, only matters because it is measured against a stable baseline across many benchmarks.

cd ../rustc-perf
cargo run --release -- bench local ../rust

You should see benchmark output and result artifacts that can be compared with later runs. If your setup is correct, the suite completes without missing toolchain errors or failed harness steps.

Step 3: Measure rustdoc improvements

This step gives you the clearest example of a large subsystem win. The article reports a 37.92% mean wall-time reduction in rustdoc and a 28% drop across all rustdoc benchmarks after combining multiple changes: less work when processing impls, better PGO training, and a cheaper sort key for impl ordering.

# Example workflow for a rustdoc-focused run
cargo run --release -- bench local ../rust --include rustdoc

You should see rustdoc benchmarks move noticeably faster than the baseline, and in a strong run the mean wall time should trend down by double digits. If you are checking instruction counts too, you should also see reductions from the smaller sort key and reduced impl processing.

Step 4: Profile Clippy dispatch overhead

The outcome of this step is a profile that shows where virtual dispatch and no-op lint calls are burning time. The source explains that Clippy traverses the AST and HIR and calls many visitor methods for every lint, even when most methods are empty. The winning fix was to combine passes so empty calls are skipped.

valgrind --tool=cachegrind cargo run -p clippy-driver -- test.rs
valgrind --tool=dhat cargo run -p clippy-driver -- test.rs

You should see high call counts and, in some cases, large branch-misprediction or copy costs. On real examples, the article says the optimized approach reduced Clippy runtime by 10-30%, with branch mispredictions down 20-80% and one stress test down 97%.

Step 5: Shrink hot data structures

This step is about turning cache pressure into measurable wins. The article shows several examples: AST expression nodes were reduced from 72 bytes to 64 bytes, which fits a cache line, and that change cut wall time by more than 10% on some AST-heavy benchmarks while lowering cache misses by as much as 29%.

// Example pattern: remove or defer rarely used fields
struct Expr {
    // smaller hot-path representation
    kind: ExprKind,
    span: Span,
    // moved out or stored elsewhere
}

You should see lower cache-miss rates and faster wall time on workloads that create lots of AST nodes. If your data structure was above 128 bytes, you may also avoid memcpy-based moves in LLVM and get an extra speedup like the 40% improvement reported for the worst new-solver crates.

Step 6: Re-run and compare the result set

Your final outcome is a clear before-and-after report that separates subsystem wins from overall compiler progress. The article’s broader result was a 5.59% mean wall-time reduction, or 2.90% if you exclude the huge rustdoc gains, so your comparison should call out both the aggregate and the local changes.

cargo run --release -- compare baseline.json latest.json
cargo run --release -- summarize latest.json

You should see a diff that lists improved benchmarks, regressions, and any noisy results that need a second look. If your numbers line up with the article’s pattern, most gains will come from a small number of targeted changes rather than one giant rewrite.

Common mistakes

• Using a noisy benchmark run as proof. Fix: rerun the suite and check whether the change survives multiple measurements.
• Optimizing one hot path without checking data layout. Fix: inspect struct sizes and cache behavior, then verify whether shrinking a type crosses the 128-byte memcpy threshold.
• Trusting automated regression reports alone. Fix: add human review for triage so noisy benchmarks and insignificant changes do not drown out real regressions.

What's next

If you want to go deeper, follow the rustc-perf dashboard, read the linked PRs from the article, and study how rustdoc PGO, Clippy pass fusion, and AST size reductions each translated into measurable wins.