rustc_codegen_ssa: Make upstream monomorphizations representation sparse by osiewicz · Pull Request #149313 · rust-lang/rust

osiewicz · 2025-11-25T13:10:03Z

Upstream monomorphisations are a blessing and a curse of Zed's build performance.

On one hand, we do benefit from it, as builds with share-generics disabled are slower for us (plus we don't really want to use nightly anyways).
On the other, deserializing query results takes a lot of time. For some crates close to the end of our compilation pipeline, it's over 400ms per crate.

To make matters worse, I've measured a hit ratio of upstream generics. A sample of such measurement goes as follows:

upstream_monomorphization returned None for 28501 distinct monomorphizations.
upstream_monomorphization returned Some 2518 times. Results came from 163 distinct CrateNums.
In total, there were 619731 instantiations to chose from (in upstream_monomorphizations() map))

This is horrid for us, as we're using a very small percentage of the map that we spend so much time deserializing from.

This commit tries to (rather clumsily) move us towards a sparse representation of upstream_monomorphizations. Instead of storing <DefId, (GenericArgsRef<'_>)> which is rather heavy to deserialize, we'll resort to storing Hashes of Instances. I plan to make this more foolproof, hence this commit is marked as WIP.
For one, we should probably keep the projection queries. Also, it might be worthwhile to store index pointing at entry within exported_generics of target crate in order to remedy a potential for collisions.

This commit reduces a touch crates/editor/src/editor.rs scenario in Zed for me from 14.5s to 11s.

bjorn3 · 2025-11-25T13:31:27Z

On the other, deserializing query results takes a lot of time. For some crates close to the end of our compilation pipeline, it's over 400ms per crate.

That is a lot. I wonder if odht could help for lazy deserialization of the DefIdMap. I don't know how easy it would be to handle with respect to deserialization and borrowing from the raw crate metadata bytes from a query though.

osiewicz · 2025-11-25T13:38:29Z

That's worth a try I guess.
It seems to only support encoding data with fixed size, which would not work with GenericArgsRef I think?

bjorn3 · 2025-11-25T13:44:41Z

Looks like it indeed. And LazyTable doesn't allow variable sized values either..

Kobzol · 2025-11-25T15:06:55Z

@bors try @rust-timer queue

…mean, r=<try> rustc_codegen_ssa: Make upstream monomorphizations representation sparse

rust-bors · 2025-11-25T17:25:46Z

☀️ Try build successful (CI)
Build commit: 4fcb6e6 (4fcb6e64fedb642e69a609c131cb6bd21443a776, parent: 7934bbdf84a6b9a30297caf4f4f38286dedf876a)

rust-timer · 2025-11-25T21:20:24Z

Finished benchmarking commit (4fcb6e6): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.1%, 0.4%]	3
Regressions ❌ (secondary)	0.4%	[0.3%, 0.5%]	4
Improvements ✅ (primary)	-0.6%	[-1.8%, -0.2%]	11
Improvements ✅ (secondary)	-0.9%	[-1.7%, -0.6%]	5
All ❌✅ (primary)	-0.5%	[-1.8%, 0.4%]	14

Max RSS (memory usage)

Results (primary -1.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.0%	[3.0%, 3.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.6%	[-2.4%, -0.8%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.1%	[-2.4%, 3.0%]	8

Cycles

Results (primary 0.9%, secondary -3.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	4.0%	[4.0%, 4.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-3.8%	[-7.5%, -2.4%]	4
All ❌✅ (primary)	0.9%	[-2.2%, 4.0%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 472.579s -> 470.697s (-0.40%)
Artifact size: 386.92 MiB -> 386.90 MiB (-0.00%)

bors · 2025-12-14T08:50:57Z

☔ The latest upstream changes (presumably #146348) made this pull request unmergeable. Please resolve the merge conflicts.

rustbot · 2026-02-10T01:14:07Z

r? @JonathanBrouwer

rustbot has assigned @JonathanBrouwer.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 21 candidates
Random selection from 13 candidates

osiewicz · 2026-02-10T01:15:09Z

Fair disclosure: I have used Claude Opus to generate code submitted in this PR.

Upstream monomorphisations are a blessing and a curse of Zed's build performance. On one hand, we do benefit from it, as builds with share-generics disabled are slower for us (plus we don't really want to use nightly anyways). On the other, deserializing query results takes *a lot* of time. For some crates close to the end of our compilation pipeline, it's over 400ms per crate. To make matters worse, I've measured a hit ratio of upstream generics. A sample of such measurement goes as follows: ``` upstream_monomorphization returned None for 28501 distinct monomorphizations. upstream_monomorphization returned Some 2518 times. Results came from 163 distinct CrateNums. In total, there are 619731 instantiations ``` This is horrid for us, as we're using a very small percentage of the map that we spend so much time deserializing from. This commit tries to (rather clumsily) move us towards a sparse representation of upstream_monomorphizations. Instead of storing <DefId, (GenericArgsRef<'_>)> which is rather heavy to deserialize, we'll resort to storing Hashes of Instances. This commit reduces a `touch crates/editor/src/editor.rs` scenario in Zed for me from 14.5s to 11s.

JonathanBrouwer · 2026-02-19T21:38:15Z

Not my area of expertise, sorry I missed this PR, oops
@rustbot reroll

cjgillot

IIUC, most of the gains from this PR avoid decoding exported_generic_symbols. Is that so?

Do you have more detailed statistics about cases where upstream_monomorphization returns None? Typical structure of the instances?

This PR introduces a heavy machinery to filter calls to exported_generic_symbols. Did you try manual filters?

For instance, early return None if the generic arguments contain a type from the current crate?

View changes since this review

cjgillot · 2026-02-22T19:40:33Z

compiler/rustc_middle/src/ty/instance.rs


        match self.def {
-            InstanceKind::Item(def) => tcx
-                .upstream_monomorphizations_for(def)


Is this query still used anywhere?

cjgillot · 2026-02-22T19:40:38Z

compiler/rustc_middle/src/ty/instance.rs

-            InstanceKind::Item(def) => tcx
-                .upstream_monomorphizations_for(def)
-                .and_then(|monos| monos.get(&self.args).cloned()),
-            InstanceKind::DropGlue(_, Some(_)) => tcx.upstream_drop_glue_for(self.args),


Is this query still used anywhere?

cjgillot · 2026-02-22T19:40:43Z

compiler/rustc_middle/src/ty/instance.rs

            InstanceKind::AsyncDropGlue(_, _) => None,
            InstanceKind::FutureDropPollShim(_, _, _) => None,
-            InstanceKind::AsyncDropGlueCtorShim(_, _) => {
-                tcx.upstream_async_drop_glue_for(self.args)


Is this query still used anywhere?

osiewicz · 2026-02-23T10:44:58Z

@cjgillot yes, the gist is to not decode exported_generic_symbols of a crate unless there's a need to.
I do not have any more concrete statistics about None-returning use case. I would actually argue that it is not that relevant. The reason is that a single miss is enough to trigger decoding of all exported generic symbols right now. And it's very easy to get such a miss. Types in std are available in all crates ¹, so in theory no matter what kind of local checks you'd have in place, you'd still have to load exported_generic_symbols of all crates to determine if any of them has instantiated Vec::<u32>::push if your local crate uses it.

The stats provided in the PRs description were useful to visualize hit ratio on this beefy upstream monomorphizations map. If it had hits on most of the queries OR the set of unique used crates was almost fully overlapping with the set of all dependencies, then there would be little to no point to using a sparse representation for it.

Yes, what this PR proposes is quite complex and I wish we could help it - guidance is most welcome. I did explore local-checks approach before abandoning it due to the "Vec dillema" described above. We need the upstream_monomorphizations query to be more granular to allow for loading just a subset of your dependency graph's exported_generic_symbols.

I did however add local checks to the construction of exported_generic_symbols in the past: #138522 and that did help with how much we needed to decode per crate. It reduced # of decoded symbols by 20% across our whole build.

I can grab the stats for you if you wish.

Well, sans no_std programs, but then we can apply the same reasoning to core. ↩

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 25, 2025