Lazily decode SourceFile from metadata

[cjgillot]

Currently, source files from foreign crates are decoded up-front from metadata.
Spans from those crates were matched with the corresponding source using binary search among those files.

This PR changes the strategy by matching spans to files during encoding. This allows to decode source files on-demand, instead of up-front. The on-disk format for spans becomes: <tag> <position from start of file> <length> <file index> <crate (if foreign file)>.

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 16ba778 with merge 7727698a1761dc5ff29971bb098c1fd11cd70852...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7727698a1761dc5ff29971bb098c1fd11cd70852 (7727698a1761dc5ff29971bb098c1fd11cd70852)

[rust-timer]

Queued 7727698a1761dc5ff29971bb098c1fd11cd70852 with parent 44bd81d, future comparison URL.

[rust-timer]

Finished benchmarking commit (7727698a1761dc5ff29971bb098c1fd11cd70852): comparison url.

Instruction count

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	0.3%	0.4%	9
Regressions 😿 (secondary)	1.0%	1.3%	4
Improvements 🎉 (primary)	-2.2%	-18.2%	43
Improvements 🎉 (secondary)	-3.2%	-17.1%	135
All 😿🎉 (primary)	-1.7%	-18.2%	52

Max RSS (memory usage)

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	1.0%	1.0%	1
Regressions 😿 (secondary)	2.3%	4.3%	4
Improvements 🎉 (primary)	-1.4%	-2.8%	3
Improvements 🎉 (secondary)	-3.6%	-7.8%	16
All 😿🎉 (primary)	-0.8%	-2.8%	4

Cycles

Results

• Primary benchmarks: 🎉 relevant improvements found
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	3.7%	3.7%	1
Improvements 🎉 (primary)	-9.6%	-10.7%	4
Improvements 🎉 (secondary)	-4.8%	-9.9%	41
All 😿🎉 (primary)	-9.6%	-10.7%	4

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[cjgillot]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit bacb4db with merge 72ee1407cb57fa4b7a2ca9feaae9cb0d325a0279...

[bors]

☀️ Try build successful - checks-actions
Build commit: 72ee1407cb57fa4b7a2ca9feaae9cb0d325a0279 (72ee1407cb57fa4b7a2ca9feaae9cb0d325a0279)

[rust-timer]

Queued 72ee1407cb57fa4b7a2ca9feaae9cb0d325a0279 with parent 5651759, future comparison URL.

[rust-timer]

Finished benchmarking commit (72ee1407cb57fa4b7a2ca9feaae9cb0d325a0279): comparison url.

Instruction count

• Primary benchmarks: 🎉 relevant improvements found
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	0.2%	0.2%	2
Regressions 😿 (secondary)	1.1%	1.4%	8
Improvements 🎉 (primary)	-1.8%	-18.2%	59
Improvements 🎉 (secondary)	-2.9%	-17.1%	152
All 😿🎉 (primary)	-1.7%	-18.2%	61

Max RSS (memory usage)

Results

• Primary benchmarks: 😿 relevant regression found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	1.0%	1.0%	1
Regressions 😿 (secondary)	2.3%	2.6%	6
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-3.2%	-6.1%	10
All 😿🎉 (primary)	1.0%	1.0%	1

Cycles

Results

• Primary benchmarks: 🎉 relevant improvements found
• Secondary benchmarks: 🎉 relevant improvements found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	-8.5%	-11.8%	5
Improvements 🎉 (secondary)	-4.8%	-11.1%	42
All 😿🎉 (primary)	-8.5%	-11.8%	5

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[cjgillot]

r? compiler

[Mark-Simulacrum]

Is it worth making this order sensitive like that? I could imagine some kind of poor effects on deterministic metadata contents -- maybe we can emit in order or even sorted by (remapped) file path?

[cjgillot]

The order of the SourceFiles here should be exactly the order in which spans are encoded. Therefore, a change in this order can only be caused by a change in encoded spans. As we can't really know which SourceFiles we will need in the end, I don't see how we can pre-sort them.

[estebank]

@bors r+

[bors]

📌 Commit 0d41f91 has been approved by estebank

It is now in the queue for this repository.

[bors]

⌛ Testing commit 0d41f91 with merge 468887e...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank
Pushing 468887e to master...

[rust-timer]

Finished benchmarking commit (468887e): comparison url.

Instruction count

• Primary benchmarks: ✅ relevant improvements found
• Secondary benchmarks: ✅ relevant improvements found

	mean1	max	count2
Regressions ❌ (primary)	0.2%	0.2%	2
Regressions ❌ (secondary)	0.7%	0.9%	3
Improvements ✅ (primary)	-1.6%	-19.6%	75
Improvements ✅ (secondary)	-3.0%	-18.3%	158
All ❌✅ (primary)	-1.6%	-19.6%	77

Max RSS (memory usage)

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions ❌ (primary)	1.7%	2.2%	5
Regressions ❌ (secondary)	3.3%	4.2%	7
Improvements ✅ (primary)	-2.1%	-2.1%	1
Improvements ✅ (secondary)	-2.6%	-3.4%	12
All ❌✅ (primary)	1.1%	2.2%	6

Cycles

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: ✅ relevant improvements found

	mean1	max	count2
Regressions ❌ (primary)	4.0%	4.0%	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-8.4%	-9.8%	4
Improvements ✅ (secondary)	-4.9%	-10.0%	38
All ❌✅ (primary)	-6.0%	-9.8%	5

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[frewsxcv]

Potentially relevant reddit thread: https://www.reddit.com/r/rust/comments/wt5vr9/compile_time_wins_today/

[klensy]

This changes encoding for Span in rmeta, shouldn't encoding in rustc_query_impl be changed too?

[cjgillot]

@klensy no. metadata and incremental cache have different formats, on purpose.
We can rely on the order given in the metadata file for the program behaviour. Everything will be recompiled when this order change.
On the other hand, the order in the incremental cache can change unpredictably between two compiler runs. (I mean: the compiler does not predict the programmers' modifications to the code.) So this format needs to recognize stuff whose order may have changed.
Does it answer your question?