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.