Remove will_cache_on_disk_for_key_fn

[zetanumbers]

Refactors QueryVtables and removes will_cache_on_disk_for_key_fn as unnecessary indirection.

Based and blocked on #154576.

Expecting perf improvements.

[lqd]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 0f75a34 (0f75a344ce44035ffe18148c5886f45b63053573, parent: cf7da0b7277cad05b79f91b60c290aa08a17a6f0)

[rust-timer]

Finished benchmarking commit (0f75a34): 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
Regressions ❌ (secondary)	0.8%	[0.8%, 0.8%]	1
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	2
Improvements ✅ (secondary)	-0.3%	[-0.6%, -0.2%]	8
All ❌✅ (primary)	-0.1%	[-0.1%, -0.1%]	2

Max RSS (memory usage)

Results (primary 4.0%, secondary 2.2%)

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)	2.2%	[2.2%, 2.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.0%	[4.0%, 4.0%]	1

Cycles

Results (primary 2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.0%	[2.0%, 2.0%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[2.0%, 2.0%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 483.836s -> 484.325s (0.10%)
Artifact size: 394.90 MiB -> 394.81 MiB (-0.02%)

[Zalathar]

Diff between the two perf runs: https://perf.rust-lang.org/compare.html?start=5a1a969187f4afe604cb916bc5740a09c5062f4b&end=0f75a344ce44035ffe18148c5886f45b63053573&stat=instructions%3Au

All of the “significicant” results look like they could be noise, unfortunately.

[zetanumbers]

Diff between the two perf runs: https://perf.rust-lang.org/compare.html?start=5a1a969187f4afe604cb916bc5740a09c5062f4b&end=0f75a344ce44035ffe18148c5886f45b63053573&stat=instructions%3Au

All of the “significicant” results look like they could be noise, unfortunately.

Why would you think that? Every ctfe-stress-5 full build benchmark seems to improve besides the doc profile because its weird I guess. While every other ctfe-stress-5 benchmark (i.e. incremental unchanged and that doc build) didn't really regressed either.

https://perf.rust-lang.org/compare.html?start=5a1a969187f4afe604cb916bc5740a09c5062f4b&end=0f75a344ce44035ffe18148c5886f45b63053573&stat=instructions%3Au&nonRelevant=true&name=ctfe-stress-5

[zetanumbers]

Either way this is also a refactor PR.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, query-system
• compiler, query-system expanded to 69 candidates
• Random selection from 12 candidates

[Zalathar]

I don’t quite understand the motivation behind this as a cleanup.

It removes a function pointer from the vtable, but replaces it with two booleans in the vtable, which doesn’t strike me as an improvement over the current code.

Is there some reason to prefer the approach in this PR?

[jieyouxu]

r? Zalathar (since you're already looking at it)

[rustbot]

Zalathar is not on the review rotation at the moment.
They may take a while to respond.

[zetanumbers]

I don’t quite understand the motivation behind this as a cleanup.

It removes a function pointer from the vtable, but replaces it with two booleans in the vtable, which doesn’t strike me as an improvement over the current code.

Is there some reason to prefer the approach in this PR?

Pair of bools is smaller than one function pointer. Removes some dynamic dispatch. Less lines of code overall.