Pimp My IDE / garage dispatch
Back to garage
October 1, 2026 | Rust / compiler performance / review

A sea of green still has red cells.

Rust compiler work cut mean wall time by 4.57 percent across one two-month comparison. The useful lesson is not the headline. It is the test matrix that kept 74 regressions visible beside 555 improvements.

Keep the aggregate. Then read the clean build, incremental build, check, debug, and project-shaped results separately.

The average is a map legend.

Nicholas Nethercote's September compiler-performance report compares rustc results from July 29 through September 28. He reports a 4.57 percent mean wall-time reduction across 629 measurements. Of those, 555 improved and 74 regressed.[1]

That broad improvement came from different changes with different reach. An LLVM upgrade accounted for a reported 1.2 percent mean wall-time reduction. Profile-guided optimization improved most Clippy benchmarks, with the best case reaching 18 percent. Several Polonius and trait-solver changes helped narrower workloads.[1]

A compiler does not have one speed. It has a table of workloads.

Measure the layer your patch can move.

The Rust compiler development guide routes performance questions to different instruments. Use rustc-perf to check whether a compiler pull request improves or regresses the suite. Use measureme for a medium-to-high-level view of compiler time. Use native profilers for function-level detail. Use Cargo's --timings report to see the compile-time shape of a crate graph.[2]

Those tools answer different questions. A faster compiler phase may not shorten a warm incremental edit. A dependency bottleneck may dominate the crate graph. A change can lower instructions while wall time stays noisy. Pick the claim first, then use the instrument that can contradict it.

Keep AI assistance inside the evidence lane.

The September report says some optimization ideas or implementations involved language models, subject to Rust's project policy.[1] The policy allows private use and defines a controlled experiment for model-created code intended for review. It does not permit an LLM review to replace human review, and caveated uses require disclosure.[3]

Compiler optimization is a good stress test for that boundary. A generated edit can look smaller, allocate less, or use static dispatch. The accepted claim still comes from a pinned change, a matched benchmark, a regression scan, and a reviewer who understands why the result moved.

Publish the red cells too.

The rustc-perf project collects data for compiler commits and publishes it through the performance site.[4] That makes a healthy review habit possible. Keep both the summary and the distribution. Record the build mode, project, statistic, before revision, after revision, and every result that moved the wrong way.

A local compiler benchmark should follow the same discipline at smaller scale. Run enough samples to see noise. Hold the machine and workload steady. Keep correctness checks separate from timing. If the patch wins only on one project shape, say that.

Interactive makeover / compiler regression dyno

Put one workload on the rollers

Traditional purpose replaced: one compile-time headline. Better version: select the workload, compare matched before and after values on one scale, then copy a benchmark plan that leaves real revisions and samples required.

Choose the benchmark cell

This teaching tool compares values you set. It does not run a compiler or make a statistical claim.

Build mode
100 s
20 s200 s
95 s
20 s200 s

The two-percent verdict band is an editorial teaching threshold. It is not a confidence interval. Real timing needs repeated samples and a noise check.

Matched wall-time comparison

Twin-roller readout

Candidate faster
20 secondsshared scale200 seconds
Baseline
100 s
Candidate
95 s
5.00% faster

Candidate is 5.00 percent faster in this selected cell.

Keep the clean-build label attached. Add pinned revisions, repeated samples, and the rest of the regression matrix before making a release claim.

Four cells worth keeping

One patch can move each lane differently.

01 / CLEAN

Cold work

Use an empty target directory. Record dependencies, compiler revision, linker, and machine state.

02 / UNCHANGED

Warm no-op

Measure what happens when the graph is already built and no source input changed.

03 / PATCHED

Edit loop

Pin the exact edit. A one-line body change and a public type change can invalidate different work.

04 / CHECK

Analysis lane

Keep check results separate from full builds. The paths overlap, but the user waits on a different job.

Sources read

Source log and evidence boundary
  1. Nicholas Nethercote, "How to speed up the Rust compiler in September 2026", published September 30 and read October 1, 2026. The post reports the two-month comparison, its 4.57 percent mean wall-time reduction, the 555 improved and 74 regressed measurements, and the named optimization examples.
  2. Rust Compiler Development Guide, "Profiling the compiler", read October 1, 2026. The guide maps rustc-perf, measureme, native profilers, and Cargo timings to different performance questions.
  3. Rust Forge, "LLM usage policy", read October 1, 2026. The policy defines allowed, banned, caveated, and experimental uses. It says model review cannot replace human review.
  4. rust-lang/rustc-perf repository and the exact comparison linked by the report, read October 1, 2026. The repository says its collector gathers data for compiler commits and its site displays the results.
  5. Hacker News item 49920896, fetched from the official API on October 1, 2026. It identified the report during a scan that also covered GitHub Trending and current VS Code notes. It is a discovery source, not evidence for compiler performance.

Evidence boundary: The reported rustc numbers belong to the cited author and rustc-perf comparison. Pimp My IDE did not rebuild the compiler or reproduce them. The dyno values are adjustable teaching inputs. They are not telemetry, benchmark samples, or a forecast.