Don't use incremental disk-cache for query predicates_of

[Zalathar]

View all comments

The predicates_of query is a relatively modest wrapper around a few underlying queries that are themselves cached to disk. Removing the additional layer of disk caching appears to be a significant perf win.

This query also appears to be the only query that uses a crate-local cache_on_disk_if condition, without also using the separate_provide_extern modifier.

• Discovered via Simplify the cache_on_disk_if query modifier to just cache_on_disk #153487 (comment)

[Zalathar]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3e7e442 (3e7e442933668f81d996b85f271eaed3a6b6dc68, parent: 80282b130679a654eaa22f028a908c51be53d436)

[rust-timer]

Finished benchmarking commit (3e7e442): 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.1%	[0.0%, 0.1%]	3
Improvements ✅ (primary)	-0.8%	[-2.0%, -0.1%]	92
Improvements ✅ (secondary)	-1.1%	[-2.6%, -0.3%]	39
All ❌✅ (primary)	-0.8%	[-2.0%, -0.1%]	92

Max RSS (memory usage)

Results (primary -1.4%, secondary 2.4%)

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)	4.4%	[3.9%, 5.2%]	4
Improvements ✅ (primary)	-1.4%	[-2.2%, -0.5%]	8
Improvements ✅ (secondary)	-1.4%	[-1.7%, -1.2%]	2
All ❌✅ (primary)	-1.4%	[-2.2%, -0.5%]	8

Cycles

Results (primary -2.7%, secondary -4.4%)

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)	-2.7%	[-3.4%, -2.3%]	8
Improvements ✅ (secondary)	-4.4%	[-8.0%, -1.6%]	7
All ❌✅ (primary)	-2.7%	[-3.4%, -2.3%]	8

Binary size

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

Bootstrap: 482.9s -> 487.171s (0.88%)
Artifact size: 397.22 MiB -> 395.20 MiB (-0.51%)

[Zalathar]

r? nnethercote (or compiler)

[nnethercote]

lol

@bors r+ r+ r+

[rust-bors]

📌 Commit c7a48e8 has been approved by nnethercote

It is now in the queue for this repository.

[Zalathar]

@bors yield

[rust-bors]

Auto build was cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/22799507331

The next pull request likely to be tested is #153387.

[rust-bors]

💔 Test for 1aa200f failed: CI. Failed job:

• auto - aarch64-gnu-llvm-20-1 (web logs, enhanced plaintext logs)

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

/dev/sda15       98M  6.4M   92M   7% /boot/efi
tmpfs           1.6G   16K  1.6G   1% /run/user/1001
================================================================================

Sufficient disk space available (120768168KB >= 52428800KB). Skipping cleanup.
##[group]Run src/ci/scripts/setup-environment.sh
src/ci/scripts/setup-environment.sh
shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
---
set -ex

# Run a subset of tests. Used to run tests in parallel in multiple jobs.

# When this job partition is run as part of PR CI, skip tidy to allow revealing more failures. The
# dedicated `tidy` job failing won't block other PR CI jobs from completing, and so tidy failures
# shouldn't inhibit revealing other failures in PR CI jobs.
if [ "$PR_CI_JOB" == "1" ]; then
  echo "PR_CI_JOB set; skipping tidy"
  SKIP_TIDY="--skip tidy"
fi

../x.py --stage 2 test \
  ${SKIP_TIDY:+$SKIP_TIDY} \
  --skip compiler \
  --skip src
#!/bin/bash

set -ex

# Run a subset of tests. Used to run tests in parallel in multiple jobs.

# When this job partition is run as part of PR CI, skip tidy to allow revealing more failures. The
# dedicated `tidy` job failing won't block other PR CI jobs from completing, and so tidy failures
# shouldn't inhibit revealing other failures in PR CI jobs.
if [ "$PR_CI_JOB" == "1" ]; then
  echo "PR_CI_JOB set; skipping tidy"
  SKIP_TIDY="--skip tidy"
fi

../x.py --stage 2 test \
  ${SKIP_TIDY:+$SKIP_TIDY} \
  --skip tests \
  --skip coverage-map \
  --skip coverage-run \
  --skip library \
  --skip tidyselftest

[Zalathar]

“Cancelled” for no reason; not sure what happened here.

@bors retry

[Zalathar]

Scheduling: No reason to do back-to-back tiny rollups before giving this another chance.

@bors p=5

[rust-bors]

☀️ Test successful - CI
Approved by: nnethercote
Duration: 4h 12m 48s
Pushing 052b9c2 to main...

[github-actions]

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 e370b60 (parent) -> 052b9c2 (this PR)

Test differences

Show 168 test diffs

168 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 052b9c23daccef254010e43d6c4d0a5459caec5b --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

1. aarch64-apple: 3h 19m -> 4h 6m (+23.5%)
2. tidy: 3m 36s -> 2m 48s (-22.3%)
3. aarch64-gnu-llvm-20-1: 1h 8m -> 58m 43s (-14.2%)
4. arm-android: 1h 48m -> 1h 36m (-10.9%)
5. dist-x86_64-apple: 2h 22m -> 2h 9m (-9.6%)
6. pr-check-1: 34m 43s -> 31m 57s (-8.0%)
7. aarch64-gnu-llvm-20-2: 53m 14s -> 49m (-7.9%)
8. dist-ohos-x86_64: 1h 13m -> 1h 18m (+7.3%)
9. dist-apple-various: 2h 6m -> 1h 57m (-7.3%)
10. x86_64-rust-for-linux: 48m 43s -> 52m 11s (+7.1%)

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]

Finished benchmarking commit (052b9c2): 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)	-	-	0
Improvements ✅ (primary)	-0.8%	[-2.0%, -0.1%]	92
Improvements ✅ (secondary)	-1.0%	[-2.6%, -0.2%]	40
All ❌✅ (primary)	-0.8%	[-2.0%, -0.1%]	92

Max RSS (memory usage)

Results (primary -0.2%, secondary 3.0%)

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

	mean	range	count
Regressions ❌ (primary)	2.4%	[1.6%, 3.2%]	2
Regressions ❌ (secondary)	4.0%	[2.5%, 4.6%]	5
Improvements ✅ (primary)	-1.1%	[-2.1%, -0.7%]	6
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	-0.2%	[-2.1%, 3.2%]	8

Cycles

Results (primary -2.6%, secondary -4.0%)

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)	-2.6%	[-3.2%, -2.2%]	7
Improvements ✅ (secondary)	-4.0%	[-6.9%, -2.1%]	10
All ❌✅ (primary)	-2.6%	[-3.2%, -2.2%]	7

Binary size

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

Bootstrap: 485.77s -> 477.657s (-1.67%)
Artifact size: 395.01 MiB -> 395.01 MiB (-0.00%)

[Kobzol]

I wonder if we could automate searching for similar "pure overhead" queries. What's the defining condition? A query cached on disk for which most of its inputs are already cached on disk?

[Zalathar]

In this case, this was the only example of a query that only disk-caches for local keys, but doesn’t use separate_provide_extern to load the same information from extern crate metadata (because the underlying queries do that).