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-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[rust-bors]

⌛ Trying commit c6d54c7 with merge 4fcb6e6…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/19674197107