rustc_metadata: track the simplified Self type for every trait impl.

[eddyb]

For the traits_impls_of query, we index the impls by fast_reject::SimplifiedType (a "shallow type"), which allows some simple cases like impl Trait<..> for Foo<..> to be efficiently iterated over, by e.g. for_each_relevant_impl.

This PR encodes the fast_reject::SimplifiedType cross-crate to avoid needing to deserialize the Self type of every impl in order to simplify it - the simplification itself should be cheap, but the deserialization is less so.

We could go further from here and make loading the list of impls lazy, for a given simplified Self type, but that would have more complicated implications for performance, and this PR doesn't do anything in that regard.

r? @nikomatsakis cc @Mark-Simulacrum

[eddyb]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 6bf3a4b with merge 128201b46cdfa059217962ae2f159583e0ae5f93...

[Mark-Simulacrum]

cc @jyn514 as well, you were asking about something similar recently

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 128201b46cdfa059217962ae2f159583e0ae5f93 (128201b46cdfa059217962ae2f159583e0ae5f93)

[rust-timer]

Queued 128201b46cdfa059217962ae2f159583e0ae5f93 with parent dfe1e3b, future comparison URL.

[jyn514]

cc @jyn514 as well, you were asking about something similar recently

This isn't quite what I was looking for ... this is making existing queries more efficient wrt metadata on disk, while #74489 is adding a new query so that looking up the traits for a type is less expensive. This looks good in and of itself though :)

[rust-timer]

Finished benchmarking try commit (128201b46cdfa059217962ae2f159583e0ae5f93): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[eddyb]

I'm very suspicious of the decrease in item_attrs getting decoded. I wonder if we could avoid that and maybe get some of the same wins? Although the biggest delta seems to be in metadata_decode_entry and I don't really know what that measures.

[nikomatsakis]

so is the performance improvement here just that we don't have to compute type_of and then simplify the type, but instead we do it "up front" when encoding?

[eddyb]

Right, I think all the cost is in decoding the Ty from type_of (simplification should be relatively cheap).

And based on the detailed query profiling info, I'm guessing it's ty::Adt containing a &'tcx ty::AdtDef instead of just a DefId, and somehow item_attrs getting called for every struct/enum/union implementing the trait (in order to create the ty::AdtDef?).

I'm suspecting this is similar to what @nnethercote was talking about a few months ago, where the deserialization of doc comment attributes was a significant cost (I don't recall what happened with that line of investigation though).

[nnethercote]

#65750 introduced a specialized representation for doc comments, that might be what you are referring to.

[nikomatsakis]

@bors r+ rollup=never

[bors]

📌 Commit 6bf3a4b has been approved by nikomatsakis

[bors]

⌛ Testing commit 6bf3a4b with merge b1bc5c61f41b461d5976940b18d09dd316a57027...

[bors]

💥 Test timed out

[JohnTitor]

@bors retry

[bors]

⌛ Testing commit 6bf3a4b with merge 3cfc7fe...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: nikomatsakis
Pushing 3cfc7fe to master...

[mati865]

Final perf result: https://perf.rust-lang.org/compare.html?start=22ee68dc586440f96b76b32fbd6087507c6afdb9&end=3cfc7fe78eccc754b16981704a098d7bd520e2fd&stat=instructions:u

Gimli regression with this PR applied: https://perf.rust-lang.org/compare.html?start=cfc572cae2d1fc381cce476b5c787fd7221af98c&end=3cfc7fe78eccc754b16981704a098d7bd520e2fd&stat=instructions%3Au
Regression definitely became smaller 🎉 but it's still far from being eliminated.

[eddyb]

That's somewhat expected, it's hard to tell what the actual wins are from relative measurements, because the delta is absolute across the board (not exactly a startup cost, but very similar for any one given trait).

I mostly went on the basis of @Mark-Simulacrum finding out that a lot of the cost was in trait_impls_of -> type_of. So this was potentially more than half of the regression (in absolute terms), but it's far from making extra dependencies free.