[perf] Specialize common (1, 1) case for arg unification.

[obi1kenobi]

View all comments

While DeepRejectCtxt::args_may_unify_inner might be called with different numbers of obligation and impl args, the (1, 1) length case is very common: single-generic-param ADTs, trait references whose only generic is Self, etc.

Offer a fast path for that simple case, so that we avoid invoking iter::zip(...).all(predicate) iterator machinery given that it isn't necessary there.

We considered, and ultimately rejected, adding a separate specialization for the (0, 0) case since benchmarks indicated it wasn't cost-effective.

r? @oli-obk

AI disclosure: The optimization opportunity here was discovered as part of a systematic probe for missed optimizations utilizing both traditional and AI tools. The code here was initially prototyped and vetted by AI tools, followed by additional manual work. I secured approval in advance from the designated reviewer. I stand behind the quality of the code I'm submitting, and I vouch it's as good or better compared to if I had written every line by my own hand.

[obi1kenobi]

cc @Kobzol for perf run

[lqd]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 08a2c83 (08a2c83fd14ebabf401ff0d6a14c0b48bbee9e1f)
Base parent: 3c00c96 (3c00c96d3af4d5b5e101e56cc161a608b21366ee)

[rust-timer]

Finished benchmarking commit (08a2c83): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing 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.3%	[-0.4%, -0.3%]	7
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.3%]	3
All ❌✅ (primary)	-0.3%	[-0.4%, -0.3%]	7

Max RSS (memory usage)

Results (primary -0.6%)

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

Cycles

Results (secondary 3.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)	3.4%	[3.4%, 3.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 491.018s -> 489.64s (-0.28%)
Artifact size: 388.45 MiB -> 388.47 MiB (0.01%)

[oli-obk]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 160aab0 (160aab06f8078e8ed680442a5f19b945262e0347)
Base parent: f10db29 (f10db292a3733b5c67c8da8c7661195ff4b05774)

[rust-timer]

Finished benchmarking commit (160aab0): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@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.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.4%	[-0.5%, -0.2%]	4
All ❌✅ (primary)	-0.2%	[-0.2%, -0.2%]	1

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Results (primary -0.1%)

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

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 487.206s -> 495.006s (1.60%)
Artifact size: 388.97 MiB -> 388.97 MiB (0.00%)

[obi1kenobi]

Having the (0, 0) case looks worse to me: we get an extra 0.06% with the new solver — a very small number compared to the significance threshold — in exchange for regressions elsewhere.

I'm planning to remove it from this PR. If I've misread the data, I'm happy to be told so and can put it back :)

[oli-obk]

View changes since this review

[rust-bors]

📌 Commit f09561b has been approved by oli-obk

It is now in the queue for this repository.

[JonathanBrouwer]

@bors yield

[rust-bors]

Auto build was cancelled. Cancelled workflows:

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

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

[JonathanBrouwer]

@bors p=6 scheduling

[rust-bors]

💔 Test for dd4afd8 failed: CI. Failed job:

• auto - x86_64-gnu-debug (web logs, enhanced plaintext logs)

[rust-log-analyzer]

The job x86_64-gnu-debug failed! Check out the build log: (web) (plain enhanced) (plain)

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

[oli-obk]

@bors retry network failure

[rust-bors]

☀️ Test successful - CI
Approved by: oli-obk
Duration: 3h 21m 25s
Pushing 3664b37 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 561ea2b (parent) -> 3664b37 (this PR)

Test differences

Show 2 test diffs

2 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 3664b37017c529cad0f0ed259769f15743c21a6a --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. x86_64-gnu-distcheck: 1h 25m -> 2h 15m (+58.1%)
2. x86_64-gnu-gcc-core-tests: 14m 8s -> 6m 18s (-55.4%)
3. x86_64-gnu-gcc: 1h 11m -> 38m 47s (-46.1%)
4. dist-i686-mingw: 2h -> 2h 43m (+35.5%)
5. dist-powerpc64le-linux-musl: 1h 8m -> 1h 30m (+33.4%)
6. dist-x86_64-mingw: 2h 32m -> 1h 42m (-32.7%)
7. dist-loongarch64-musl: 1h 40m -> 1h 10m (-29.8%)
8. i686-gnu-2: 1h 44m -> 1h 13m (-29.4%)
9. x86_64-msvc-1: 2h 38m -> 1h 55m (-27.0%)
10. i686-msvc-2: 2h 3m -> 1h 31m (-26.2%)

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 (3664b37): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.2%	[0.2%, 0.2%]	1
Regressions ❌ (secondary)	0.2%	[0.2%, 0.3%]	7
Improvements ✅ (primary)	-0.5%	[-0.7%, -0.2%]	8
Improvements ✅ (secondary)	-0.3%	[-0.5%, -0.1%]	6
All ❌✅ (primary)	-0.4%	[-0.7%, 0.2%]	9

Max RSS (memory usage)

Results (secondary 6.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)	6.0%	[6.0%, 6.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (primary -2.9%, secondary 9.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)	15.5%	[14.4%, 16.6%]	2
Improvements ✅ (primary)	-2.9%	[-2.9%, -2.9%]	1
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	-2.9%	[-2.9%, -2.9%]	1

Binary size

Results (primary -0.1%, secondary -0.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)	-0.1%	[-0.1%, -0.0%]	52
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.0%]	22
All ❌✅ (primary)	-0.1%	[-0.1%, -0.0%]	52

Bootstrap: 489.147s -> 487.967s (-0.24%)
Artifact size: 388.47 MiB -> 388.37 MiB (-0.03%)

[obi1kenobi]

I noticed something curious in the benchmark data for this reported regression and wanted to flag it for the regression triage.

In the original benchmark report (first timer post above), the improvements were in typenum and in bitmaps, in various profiles. We see those improvements again in the new report.

The regressions in the new report are in unicode-normalization and tuple-stress, which did not see regressions in the original report.

However, go from the new report to the immediately previous report, on the previous commit. You'll see improvements in unicode-normalization and tuple-stress — the exact regressed packages. The magnitude of the improvement and subsequent regression are effectively identical.

To my eyes, this looks like the previous build got lucky (perhaps BOLT/PGO/LTO?) in those benchmarks, and the next build (this PR) simply experienced a return to the prior performance level.