rustc_codegen_ssa: Make upstream monomorphizations representation sparse

[osiewicz]

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]

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]

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]

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

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

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

[rust-timer]

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]

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

[rustbot]

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]

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

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

fmt: checked 6697 files
tidy check
tidy [rustdoc_json (src)]: `rustdoc-json-types` modified, checking format version
tidy: Skipping binary file check, read-only filesystem
tidy [alphabetical (compiler)]: /checkout/compiler/rustc_metadata/src/rmeta/parameterized.rs:71: line not in alphabetical order (tip: use --bless to sort this list)
tidy [alphabetical (compiler)]: FAIL
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'venv'
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'virtualenv'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (25.3)
Collecting pip
---
info: ES-Check: there were no ES version matching errors!  🎉
typechecking javascript files
tidy: The following check failed: alphabetical (compiler)
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy --root-path=/checkout --cargo-path=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo --output-dir=/checkout/obj/build --concurrency=4 --npm-path=/node/bin/yarn --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1612:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1365:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:02:55
  local time: Tue Feb 10 01:27:09 UTC 2026
  network time: Tue, 10 Feb 2026 01:27:09 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"