Rust compiler: new span format interns 1% of spans, not 20-40%; Diesel gap narrows
Serguey Asael Shinder2 min readNicholas Nethercote has published his November update on Rust compiler performance, written after his first month working on the subject for Hexcat. The largest change is to spans, the data structure every AST, HIR and MIR node carries to record a source location, hygiene context and an optional parent position.
A span holds four 32-bit fields, 16 bytes in all, but is usually compressed into one of three 8-byte inline formats, with the rest interned into a global table. In PR 163857 Nethercote replaced the compression scheme with a simpler one. For incremental builds the compiler now typically interns around 1% of spans, against 20 to 40% before; in non-incremental builds fewer than 0.1%. The context field can now always be stored inline. Instruction counts fell across many benchmarks, by more than 3% in the best cases, with larger cycle-count gains, and incremental builds benefited most. Josh Triplett then used the new layout to micro-optimise span operations in PR 163971, for up to a further 2%.
PR 163628 put a single-entry cache in front of the hash table that metadata encoding and stable hashing query for the same parent span over and over, cutting instruction counts by more than 4% in the best case, again mostly for incremental compilation. An experiment to give Span a niche so that an optional span takes no extra space worked but did not help performance and was abandoned.
On the in-development new trait solver, three PRs targeted Diesel, where the new solver is slower than the old one. A dozen micro-optimisations reduced the new solver's instruction-count overhead on a full check build from 1.49x to 1.16x; typenum and nalgebra also improved.
What it means
Incremental builds are where most of these gains land, which is where developers wait most. The new solver's remaining gap on heavy generic crates is now measured and shrinking.