Improve the forcing/promotion functions in `DepKindVTable` by Zalathar · Pull Request #153122 · rust-lang/rust

Zalathar · 2026-02-26T07:51:09Z

This is a bundle of changes to the two function pointers in DepKindVTable that are responsible for forcing dep nodes, or promoting disk-cached values from the previous session into memory.

The perf improvements to incr-unchanged and incr-patched are likely from skipping more of the “promotion” plumbing for queries that never cache to disk.

Zalathar · 2026-02-26T07:51:51Z

This is not fully-baked yet, but I want to run PR CI and perf to check for unanticipated problems.

@bors try @rust-timer queue

Improve the forcing/promotion functions in `DepKindVTable`

compiler/rustc_query_impl/src/dep_kind_vtables.rs

rust-bors · 2026-02-26T10:02:16Z

☀️ Try build successful (CI)
Build commit: dff6afa (dff6afa28aa02dfe76c0d36c5fc140333bf99233, parent: 1ed488274bec5bf5cfe6bf7a1cc089abcc4ebd68)

rust-timer · 2026-02-26T10:41:57Z

Finished benchmarking commit (dff6afa): comparison URL.

Overall result: ✅ improvements - no action needed

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.

@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
Improvements ✅ (primary)	-0.8%	[-1.7%, -0.2%]	102
Improvements ✅ (secondary)	-1.2%	[-6.5%, -0.2%]	68
All ❌✅ (primary)	-0.8%	[-1.7%, -0.2%]	102

Max RSS (memory usage)

Results (primary -3.7%, secondary 4.3%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	8.2%	[8.1%, 8.2%]	2
Improvements ✅ (primary)	-3.7%	[-3.7%, -3.7%]	1
Improvements ✅ (secondary)	-3.4%	[-3.4%, -3.4%]	1
All ❌✅ (primary)	-3.7%	[-3.7%, -3.7%]	1

Cycles

Results (primary -3.1%, secondary -8.1%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.1%	[-3.2%, -3.1%]	2
Improvements ✅ (secondary)	-8.1%	[-18.7%, -2.7%]	7
All ❌✅ (primary)	-3.1%	[-3.2%, -3.1%]	2

Binary size

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

Bootstrap: 492.161s -> 478.802s (-2.71%)
Artifact size: 395.78 MiB -> 397.55 MiB (0.45%)

Zalathar · 2026-02-27T01:17:23Z

r? nnethercote (or compiler)

nnethercote · 2026-02-27T01:57:27Z

Fantastic perf results!

I would like to eliminate GetQueryVTable if possible. I think it might be possible if each normal query's DepKindVTable had a pointer to its QueryVTable. But not in this PR.

@bors r+

rust-bors · 2026-02-27T01:57:30Z

📌 Commit 3b6451e has been approved by nnethercote

It is now in the queue for this repository.

Zalathar · 2026-02-27T02:47:06Z

I would like to eliminate GetQueryVTable if possible. I think it might be possible if each normal query's DepKindVTable had a pointer to its QueryVTable. But not in this PR.

Right now, GetQueryVTable is what allows DepKindVTable to not know about query key/value/cache types at all, because that knowledge is baked into the different generic instantiations of its function pointers instead.

So I currently don't see a way to usefully put a query-vtable pointer into DepKindVTable.

Zoxc · 2026-02-27T21:16:35Z

compiler/rustc_middle/src/dep_graph/mod.rs

+    /// True if a key can _potentially_ be recovered from a key fingerprint
+    /// with this style.
+    ///
+    /// For some key types, recovery is possible but not guaranteed.


This seems a bit misleading. Do we have any types where recovery will fail?

Yes, it's possible for DefId to fail recovery, for example.

I verified this by adding a panic to the failure path of one of the try_recover_key calls, and then running x test incremental.

- `force_from_dep_node` → `force_from_dep_node_fn` - `try_load_from_disk_cache` → `promote_from_disk_fn` This commit also inlines the wrapper function around `promote_from_disk_fn`.

rustbot · 2026-03-01T08:42:33Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Zalathar · 2026-03-01T08:43:12Z

Rebased to fix trivial conflict.

@bors r=nnethercote

rust-bors · 2026-03-01T08:43:15Z

📌 Commit 08df254 has been approved by nnethercote

It is now in the queue for this repository.

rust-bors · 2026-03-01T19:44:24Z

☀️ Test successful - CI
Approved by: nnethercote
Duration: 3h 15m 52s
Pushing 28b5c1c to main...

github-actions · 2026-03-01T19:47:29Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 024757f (parent) -> 28b5c1c (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 28b5c1cc084d3d21168f034b39c23193a9a7f127 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

x86_64-rust-for-linux: 42m 15s -> 53m 34s (+26.8%)
dist-i586-gnu-i586-i686-musl: 1h 22m -> 1h 35m (+16.2%)
pr-check-1: 29m 8s -> 33m 43s (+15.8%)
aarch64-gnu-llvm-20-1: 53m 42s -> 1h 2m (+15.4%)
dist-aarch64-llvm-mingw: 1h 28m -> 1h 41m (+15.2%)
i686-gnu-1: 2h 1m -> 2h 16m (+13.0%)
dist-aarch64-apple: 2h 1m -> 1h 46m (-12.3%)
test-various: 1h 51m -> 2h 5m (+12.2%)
x86_64-gnu-llvm-21-3: 1h 44m -> 1h 56m (+12.1%)
i686-gnu-2: 1h 29m -> 1h 40m (+12.0%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-03-01T20:26:17Z

Finished benchmarking commit (28b5c1c): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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)	1.9%	[1.9%, 1.9%]	1
Improvements ✅ (primary)	-0.8%	[-1.7%, -0.3%]	102
Improvements ✅ (secondary)	-1.2%	[-6.5%, -0.2%]	68
All ❌✅ (primary)	-0.8%	[-1.7%, -0.3%]	102

Max RSS (memory usage)

Results (secondary -2.7%)

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

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

Cycles

Results (primary -3.0%, secondary -6.3%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.0%	[-3.0%, -2.9%]	2
Improvements ✅ (secondary)	-6.3%	[-15.9%, -2.9%]	11
All ❌✅ (primary)	-3.0%	[-3.0%, -2.9%]	2

Binary size

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

Bootstrap: 477.708s -> 479.821s (0.44%)
Artifact size: 397.23 MiB -> 397.02 MiB (-0.05%)

This comment has been minimized.

Sign in to view

rust-bors bot pushed a commit that referenced this pull request Feb 26, 2026

Auto merge of #153122 - Zalathar:dep-kind-vtable, r=<try>

dff6afa

Improve the forcing/promotion functions in `DepKindVTable`

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 26, 2026

Zalathar commented Feb 26, 2026

View reviewed changes

compiler/rustc_query_impl/src/dep_kind_vtables.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 26, 2026

Zalathar force-pushed the dep-kind-vtable branch 3 times, most recently from 2aba5f0 to 3b6451e Compare February 26, 2026 22:56

rustbot assigned nnethercote Feb 27, 2026

Zalathar marked this pull request as ready for review February 27, 2026 01:17

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 27, 2026

nnethercote approved these changes Feb 27, 2026

View reviewed changes

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 27, 2026

Zoxc reviewed Feb 27, 2026

View reviewed changes

rust-bors bot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 1, 2026

This comment has been minimized.

Sign in to view

rust-bors bot removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 1, 2026

Zalathar added 4 commits March 1, 2026 19:41

Rename the function pointers in DepKindVTable

c0e7a43

- `force_from_dep_node` → `force_from_dep_node_fn` - `try_load_from_disk_cache` → `promote_from_disk_fn` This commit also inlines the wrapper function around `promote_from_disk_fn`.

Avoid some trivial wrapper closures in DepKindVTable

4284edc

Explain why some queries don't support forcing/promotion

f7ac426

Don't try to promote queries that never cache to disk

08df254

Zalathar force-pushed the dep-kind-vtable branch from 3b6451e to 08df254 Compare March 1, 2026 08:42

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 1, 2026

This comment has been minimized.

Sign in to view

rust-bors bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 1, 2026

rust-bors bot merged commit 28b5c1c into rust-lang:main Mar 1, 2026
12 checks passed

rustbot added this to the 1.96.0 milestone Mar 1, 2026

This was referenced Mar 1, 2026

Lint unused features #152164

Open

Rejig rustc_with_all_queries! #153161

Merged

Zalathar deleted the dep-kind-vtable branch March 1, 2026 22:41

Uh oh!

Conversation

Zalathar commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Zalathar commented Feb 26, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

This comment has been minimized.

rust-bors bot commented Feb 26, 2026

Uh oh!

This comment has been minimized.

rust-timer commented Feb 26, 2026

Overall result: ✅ improvements - no action needed

Uh oh!

Zalathar commented Feb 27, 2026

Uh oh!

nnethercote commented Feb 27, 2026

Uh oh!

rust-bors bot commented Feb 27, 2026

Uh oh!

Zalathar commented Feb 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rustbot commented Mar 1, 2026

Uh oh!

Zalathar commented Mar 1, 2026

Uh oh!

rust-bors bot commented Mar 1, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Mar 1, 2026

Uh oh!

Uh oh!

github-actions bot commented Mar 1, 2026

Test differences

Job duration changes

Uh oh!

rust-timer commented Mar 1, 2026

Overall result: ✅ improvements - no action needed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Zalathar commented Feb 26, 2026 •

edited

Loading