A community Rust compiler patch cuts clean builds up to 42% on real codebases

A community patch series to the open-source Rust compiler reports clean-build speedups of up to 54% on cargo check and up to 42% on cargo build across 13 real-world codebases on 16-core machines, with no project measured as slower. The author has not asked for a merge, and the work needs a nightly compiler and a patched build tool to run.

The project is called headstart, and it lands as six patches to rustc (the Rust compiler) and three patches to cargo (Rust's build tool). The mechanism is a rewrite of where in the pipeline the compiler emits crate metadata, the small files that describe a crate's public type signatures so other crates can use them. In stock rustc, that file is written only after every function body has been type-checked. In headstart, the compiler writes a partial metadata file as soon as it has finished checking just the item interfaces: the function signatures, struct definitions, and trait declarations. Only then does it start the longer pass that checks the bodies.

On cargo check, where the goal is only to validate the whole program against the type system, dependents can run to completion on the early metadata. On cargo build, they can do all of their own analysis on the early metadata, then park on a lock while they wait for the full body-checked metadata before generating machine code. The cargo patches are the part that does the parking, the design doc explains.

The numbers, as the patch author reports them, are ceiling figures, not medians, and they are tightly scoped. The results doc lists per-project medians of 35% on serde_derive for cargo check, 34% on tt-muncher, 29 to 36% on clap_derive, 26 to 36% on unicode-normalization, 24 to 27% on html5ever, 20 to 24% on hyper, and 22% on wg-grammar. The full set of 13 projects, which includes rust-analyzer, zed, bevy, lemmy, and polars, was measured with the same patched rustc and alternating runs with and without the headstart flags. No project came out slower in the author's runs.

Those gains do not transfer cleanly to smaller machines. On 4 cores, the readiness doc reports rust-analyzer at 24% faster on cargo check and 13 to 15% faster on cargo build, codex-rs 14% faster on cargo check, and the wide multi-crate builds roughly break even. A parallel-front-end flag, -Zthreads=8, already exists in nightly and adds up to 25% on top in the author's tests, so some of the same ground is already covered by an upstream feature.

The author runs a separate verification step. The patch ships with -Zearly-metadata-verify, which re-runs dependent analysis against the full metadata after the build. Across 53 benchmark sweeps with that flag enabled, 312 real-project builds, and the full upstream rustc UI test suite of 22,172 cases, the readiness doc reports diagnostics and exit statuses identical to stock rustc. The source is still self-published: there is no independent benchmarker in the supplied material, and the Hacker News thread on the release is small.

Dependent work that runs on early metadata gets thrown away if the dependency's body check later errors, so a failing build can do more work before reporting. Error messages are the same, but they show up slightly later. Peak memory is higher because more crates sit in memory at once. The patch also requires a nightly rustc and a patched cargo, so it does not run on any user who can install a stable release today.

The upstream path is the live constraint. The readiness doc lists the open work as the MCP (minimum-merge-prep) checklist and a fresh round of 16- and 8-core runs, and the author has not requested a merge. Until a rustc maintainer picks this up, the speedup lives behind a flag, on a nightly compiler, with a patched build tool, on a single author's numbers.