MIR body serialization may be a bottleneck

[oli-obk]

During MIR inlining, we end up producing larger MIR bodies each, as inlining often causes an increase in MIR for non-trivial functions being inlined. This perf run shows that in the incremental cases, we lose some time to optimized_mir as expected but this is often offset by wins in codegen.

However the other place we regress is time spent dealing with the incremental cache. That suggests to me that our MIR is larger due to inlining which causes more time to be spent during serialization/deserialization.

It might be worth exploring if there's any optimizations we can make to the serialized Body representation.

Originally posted by @wesleywiser in #68828 (comment)

[tmiasko]

Decoding of foreign spans is one of hotspots quite unique to builds with inlining:

rust/compiler/rustc_metadata/src/rmeta/decoder.rs

Lines 485 to 492 in 9320b12

	// Decoding 'foreign' spans should be rare enough that it's
	// not worth it to maintain a per-CrateNum cache for `last_source_file_index`.
	// We just set it to 0, to ensure that we don't try to access something out
	// of bounds for our initial 'guess'
	decoder.last_source_file_index = 0;
	let foreign_data = decoder.cdata().cstore.get_crate_data(cnum);
	foreign_data.imported_source_files(sess)