fast-reject: add depth check #133566

lcnr · 2024-11-28T09:16:24Z

slightly modified version of #133524

I tried a few alternatives:

simply bail after recursion for a certain amount of times, looking at the number of steps taken while compiling different crates we get the following results¹. As we need a fairly high limit here using one felt somewhat arbitrary, it also had a slightly larger performance impact than the final approach

typenum

1098842 counts
(  1)   670511 (61.0%, 61.0%): dropping after 1
(  2)   358785 (32.7%, 93.7%): dropping after 0
(  3)    25191 ( 2.3%, 96.0%): dropping after 2
(  4)    10912 ( 1.0%, 97.0%): dropping after 4
(  5)     6461 ( 0.6%, 97.5%): dropping after 3
(  6)     5239 ( 0.5%, 98.0%): dropping after 5
(  7)     2528 ( 0.2%, 98.3%): dropping after 8
(  8)     2188 ( 0.2%, 98.5%): dropping after 1094
(  9)     2097 ( 0.2%, 98.6%): dropping after 6
( 10)     1179 ( 0.1%, 98.7%): dropping after 34
( 11)     1148 ( 0.1%, 98.9%): dropping after 7
( 12)      822 ( 0.1%, 98.9%): dropping after 10

bitmaps

533346 counts
(  1)   526166 (98.7%, 98.7%): dropping after 1
(  2)     4562 ( 0.9%, 99.5%): dropping after 0
(  3)     2072 ( 0.4%, 99.9%): dropping after 1024
(  4)      305 ( 0.1%,100.0%): dropping after 2
(  5)      106 ( 0.0%,100.0%): dropping after 4
(  6)       30 ( 0.0%,100.0%): dropping after 8
(  7)       18 ( 0.0%,100.0%): dropping after 3
(  8)       17 ( 0.0%,100.0%): dropping after 44
(  9)       15 ( 0.0%,100.0%): dropping after 168
( 10)        8 ( 0.0%,100.0%): dropping after 14
( 11)        7 ( 0.0%,100.0%): dropping after 13
( 12)        7 ( 0.0%,100.0%): dropping after 24

stage 2 compiler is mostly trivial, but has a few cases where we get >5000

12987156 counts
(  1)  9280476 (71.5%, 71.5%): dropping after 0
(  2)  2277841 (17.5%, 89.0%): dropping after 1
(  3)   724888 ( 5.6%, 94.6%): dropping after 2
(  4)   204005 ( 1.6%, 96.2%): dropping after 4
(  5)   146537 ( 1.1%, 97.3%): dropping after 3
(  6)    64287 ( 0.5%, 97.8%): dropping after 5
(  7)    43938 ( 0.3%, 98.1%): dropping after 6
(  8)    43758 ( 0.3%, 98.4%): dropping after 8
(  9)    27220 ( 0.2%, 98.7%): dropping after 7
( 10)    17374 ( 0.1%, 98.8%): dropping after 9
( 11)    16015 ( 0.1%, 98.9%): dropping after 10
( 12)    12855 ( 0.1%, 99.0%): dropping after 12
( 13)    10494 ( 0.1%, 99.1%): dropping after 11
( 14)     7553 ( 0.1%, 99.2%): dropping after 14

add a cache: results in a bigger performance impact

r? @compiler-errors

i've incremented a counter in the place I now decrement the depth at and then printed it on drop ↩

lcnr · 2024-11-28T09:16:30Z

@bors try @rust-timer queue

bors · 2024-11-28T09:17:41Z

⌛ Trying commit 4ebc6c8 with merge 96e2f40...

fast-reject: add counter to avoid hangs alternative approach to rust-lang#133524 r? `@compiler-errors`

bors · 2024-11-28T11:04:32Z

☀️ Try build successful - checks-actions
Build commit: 96e2f40 (96e2f4001545070abb73af5078f4ea5120c9ac43)

compiler-errors · 2024-11-28T11:09:38Z

if this ends up neutral then r=me

rust-timer · 2024-11-28T19:59:21Z

Finished benchmarking commit (96e2f40): comparison URL.

Overall result: ❌ regressions - please read the text below

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-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary 1.0%, secondary -2.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.6%	[0.6%, 3.5%]	7
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-2.9%	[-2.9%, -2.9%]	1
All ❌✅ (primary)	1.0%	[-2.8%, 3.5%]	8

Cycles

Results (primary 4.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	4.9%	[0.9%, 6.4%]	8
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.9%	[0.9%, 6.4%]	8

Binary size

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

Bootstrap: 792.58s -> 793.229s (0.08%)
Artifact size: 335.88 MiB -> 335.76 MiB (-0.04%)

oli-obk · 2024-11-29T05:14:07Z

compiler/rustc_type_ir/src/fast_reject.rs

@@ -273,6 +278,12 @@ impl<I: Interner, const INSTANTIATE_LHS_WITH_INFER: bool, const INSTANTIATE_RHS_
            | ty::Placeholder(_) => {}
        };

+        self.num_non_trivial_types += 1;


Maybe move this into a wrapper around types_may_unify to only pay the cost when recursing?

the biggest one is typenum, tbh I would not be surprised if typenum actually relies on fast reject with large enough types

Oh... yea I think we can treat typenum "regressions below 100% are fine" if sufficiently motivated. Which this PR is.

lcnr · 2024-11-29T09:55:16Z

@bors try @rust-timer queue

fast-reject: add cache slightly modified version of rust-lang#133524 I originally wanted to simply bail after recursion for a certain amount of times, however, looking at the number of steps taken while compiling different crates we get the following results[^1]: typenum ```rust 1098842 counts ( 1) 670511 (61.0%, 61.0%): dropping after 1 ( 2) 358785 (32.7%, 93.7%): dropping after 0 ( 3) 25191 ( 2.3%, 96.0%): dropping after 2 ( 4) 10912 ( 1.0%, 97.0%): dropping after 4 ( 5) 6461 ( 0.6%, 97.5%): dropping after 3 ( 6) 5239 ( 0.5%, 98.0%): dropping after 5 ( 7) 2528 ( 0.2%, 98.3%): dropping after 8 ( 8) 2188 ( 0.2%, 98.5%): dropping after 1094 ( 9) 2097 ( 0.2%, 98.6%): dropping after 6 ( 10) 1179 ( 0.1%, 98.7%): dropping after 34 ( 11) 1148 ( 0.1%, 98.9%): dropping after 7 ( 12) 822 ( 0.1%, 98.9%): dropping after 10 ``` bitmaps ```rust 533346 counts ( 1) 526166 (98.7%, 98.7%): dropping after 1 ( 2) 4562 ( 0.9%, 99.5%): dropping after 0 ( 3) 2072 ( 0.4%, 99.9%): dropping after 1024 ( 4) 305 ( 0.1%,100.0%): dropping after 2 ( 5) 106 ( 0.0%,100.0%): dropping after 4 ( 6) 30 ( 0.0%,100.0%): dropping after 8 ( 7) 18 ( 0.0%,100.0%): dropping after 3 ( 8) 17 ( 0.0%,100.0%): dropping after 44 ( 9) 15 ( 0.0%,100.0%): dropping after 168 ( 10) 8 ( 0.0%,100.0%): dropping after 14 ( 11) 7 ( 0.0%,100.0%): dropping after 13 ( 12) 7 ( 0.0%,100.0%): dropping after 24 ``` stage 2 compiler is mostly trivial, but has a few cases where we get >5000 ```rust 12987156 counts ( 1) 9280476 (71.5%, 71.5%): dropping after 0 ( 2) 2277841 (17.5%, 89.0%): dropping after 1 ( 3) 724888 ( 5.6%, 94.6%): dropping after 2 ( 4) 204005 ( 1.6%, 96.2%): dropping after 4 ( 5) 146537 ( 1.1%, 97.3%): dropping after 3 ( 6) 64287 ( 0.5%, 97.8%): dropping after 5 ( 7) 43938 ( 0.3%, 98.1%): dropping after 6 ( 8) 43758 ( 0.3%, 98.4%): dropping after 8 ( 9) 27220 ( 0.2%, 98.7%): dropping after 7 ( 10) 17374 ( 0.1%, 98.8%): dropping after 9 ( 11) 16015 ( 0.1%, 98.9%): dropping after 10 ( 12) 12855 ( 0.1%, 99.0%): dropping after 12 ( 13) 10494 ( 0.1%, 99.1%): dropping after 11 ( 14) 7553 ( 0.1%, 99.2%): dropping after 14 ``` Given that we have crates which frequently rely on fairly deep recursion, actually using a cache seems better than using an arbitrary cutoff here. Having an impl which is large enough to trigger a cutoff instead of getting rejected noticeably impacts perf, so just using a cache in these cases seems better to me. Does not matter too much in the end, we only have to make sure we don't regress crates which don't recurse deeply. [^1]: i've incremented a counter in the place I now call `if cache.get(&(lhs, rhs))` and then printed it on drop r? `@compiler-errors`

bors · 2024-11-29T09:56:27Z

⌛ Trying commit f6f4396 with merge 613c078...

bors · 2024-11-29T11:39:27Z

☀️ Try build successful - checks-actions
Build commit: 613c078 (613c0785c6449a40bc487d06bfe5437075aa7dec)

rust-timer · 2024-11-29T12:56:16Z

Finished benchmarking commit (613c078): comparison URL.

Overall result: ❌ regressions - please read the text below

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-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	1.1%	[0.1%, 2.1%]	16
Regressions ❌ (secondary)	0.9%	[0.9%, 0.9%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[0.1%, 2.1%]	16

Max RSS (memory usage)

Results (primary -1.3%, secondary 3.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

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

Binary size

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

Bootstrap: 773.306s -> 773.019s (-0.04%)
Artifact size: 331.98 MiB -> 332.05 MiB (0.02%)

bors · 2024-11-29T16:33:20Z

⌛ Trying commit 0dc67dc with merge 355514c...

fast-reject: add cache slightly modified version of rust-lang#133524 I originally wanted to simply bail after recursion for a certain amount of times, however, looking at the number of steps taken while compiling different crates we get the following results[^1]: typenum ```rust 1098842 counts ( 1) 670511 (61.0%, 61.0%): dropping after 1 ( 2) 358785 (32.7%, 93.7%): dropping after 0 ( 3) 25191 ( 2.3%, 96.0%): dropping after 2 ( 4) 10912 ( 1.0%, 97.0%): dropping after 4 ( 5) 6461 ( 0.6%, 97.5%): dropping after 3 ( 6) 5239 ( 0.5%, 98.0%): dropping after 5 ( 7) 2528 ( 0.2%, 98.3%): dropping after 8 ( 8) 2188 ( 0.2%, 98.5%): dropping after 1094 ( 9) 2097 ( 0.2%, 98.6%): dropping after 6 ( 10) 1179 ( 0.1%, 98.7%): dropping after 34 ( 11) 1148 ( 0.1%, 98.9%): dropping after 7 ( 12) 822 ( 0.1%, 98.9%): dropping after 10 ``` bitmaps ```rust 533346 counts ( 1) 526166 (98.7%, 98.7%): dropping after 1 ( 2) 4562 ( 0.9%, 99.5%): dropping after 0 ( 3) 2072 ( 0.4%, 99.9%): dropping after 1024 ( 4) 305 ( 0.1%,100.0%): dropping after 2 ( 5) 106 ( 0.0%,100.0%): dropping after 4 ( 6) 30 ( 0.0%,100.0%): dropping after 8 ( 7) 18 ( 0.0%,100.0%): dropping after 3 ( 8) 17 ( 0.0%,100.0%): dropping after 44 ( 9) 15 ( 0.0%,100.0%): dropping after 168 ( 10) 8 ( 0.0%,100.0%): dropping after 14 ( 11) 7 ( 0.0%,100.0%): dropping after 13 ( 12) 7 ( 0.0%,100.0%): dropping after 24 ``` stage 2 compiler is mostly trivial, but has a few cases where we get >5000 ```rust 12987156 counts ( 1) 9280476 (71.5%, 71.5%): dropping after 0 ( 2) 2277841 (17.5%, 89.0%): dropping after 1 ( 3) 724888 ( 5.6%, 94.6%): dropping after 2 ( 4) 204005 ( 1.6%, 96.2%): dropping after 4 ( 5) 146537 ( 1.1%, 97.3%): dropping after 3 ( 6) 64287 ( 0.5%, 97.8%): dropping after 5 ( 7) 43938 ( 0.3%, 98.1%): dropping after 6 ( 8) 43758 ( 0.3%, 98.4%): dropping after 8 ( 9) 27220 ( 0.2%, 98.7%): dropping after 7 ( 10) 17374 ( 0.1%, 98.8%): dropping after 9 ( 11) 16015 ( 0.1%, 98.9%): dropping after 10 ( 12) 12855 ( 0.1%, 99.0%): dropping after 12 ( 13) 10494 ( 0.1%, 99.1%): dropping after 11 ( 14) 7553 ( 0.1%, 99.2%): dropping after 14 ``` Given that we have crates which frequently rely on fairly deep recursion, actually using a cache seems better than using an arbitrary cutoff here. Having an impl which is large enough to trigger a cutoff instead of getting rejected noticeably impacts perf, so just using a cache in these cases seems better to me. Does not matter too much in the end, we only have to make sure we don't regress crates which don't recurse deeply. [^1]: i've incremented a counter in the place I now call `if cache.get(&(lhs, rhs))` and then printed it on drop r? `@compiler-errors`

lcnr · 2024-11-29T17:02:32Z

@bors try @rust-timer queue

bors · 2024-11-29T17:03:43Z

⌛ Trying commit 3465ce5 with merge 2b0fb20...

fast-reject: add cache slightly modified version of rust-lang#133524 I originally wanted to simply bail after recursion for a certain amount of times, however, looking at the number of steps taken while compiling different crates we get the following results[^1]: typenum ```rust 1098842 counts ( 1) 670511 (61.0%, 61.0%): dropping after 1 ( 2) 358785 (32.7%, 93.7%): dropping after 0 ( 3) 25191 ( 2.3%, 96.0%): dropping after 2 ( 4) 10912 ( 1.0%, 97.0%): dropping after 4 ( 5) 6461 ( 0.6%, 97.5%): dropping after 3 ( 6) 5239 ( 0.5%, 98.0%): dropping after 5 ( 7) 2528 ( 0.2%, 98.3%): dropping after 8 ( 8) 2188 ( 0.2%, 98.5%): dropping after 1094 ( 9) 2097 ( 0.2%, 98.6%): dropping after 6 ( 10) 1179 ( 0.1%, 98.7%): dropping after 34 ( 11) 1148 ( 0.1%, 98.9%): dropping after 7 ( 12) 822 ( 0.1%, 98.9%): dropping after 10 ``` bitmaps ```rust 533346 counts ( 1) 526166 (98.7%, 98.7%): dropping after 1 ( 2) 4562 ( 0.9%, 99.5%): dropping after 0 ( 3) 2072 ( 0.4%, 99.9%): dropping after 1024 ( 4) 305 ( 0.1%,100.0%): dropping after 2 ( 5) 106 ( 0.0%,100.0%): dropping after 4 ( 6) 30 ( 0.0%,100.0%): dropping after 8 ( 7) 18 ( 0.0%,100.0%): dropping after 3 ( 8) 17 ( 0.0%,100.0%): dropping after 44 ( 9) 15 ( 0.0%,100.0%): dropping after 168 ( 10) 8 ( 0.0%,100.0%): dropping after 14 ( 11) 7 ( 0.0%,100.0%): dropping after 13 ( 12) 7 ( 0.0%,100.0%): dropping after 24 ``` stage 2 compiler is mostly trivial, but has a few cases where we get >5000 ```rust 12987156 counts ( 1) 9280476 (71.5%, 71.5%): dropping after 0 ( 2) 2277841 (17.5%, 89.0%): dropping after 1 ( 3) 724888 ( 5.6%, 94.6%): dropping after 2 ( 4) 204005 ( 1.6%, 96.2%): dropping after 4 ( 5) 146537 ( 1.1%, 97.3%): dropping after 3 ( 6) 64287 ( 0.5%, 97.8%): dropping after 5 ( 7) 43938 ( 0.3%, 98.1%): dropping after 6 ( 8) 43758 ( 0.3%, 98.4%): dropping after 8 ( 9) 27220 ( 0.2%, 98.7%): dropping after 7 ( 10) 17374 ( 0.1%, 98.8%): dropping after 9 ( 11) 16015 ( 0.1%, 98.9%): dropping after 10 ( 12) 12855 ( 0.1%, 99.0%): dropping after 12 ( 13) 10494 ( 0.1%, 99.1%): dropping after 11 ( 14) 7553 ( 0.1%, 99.2%): dropping after 14 ``` Given that we have crates which frequently rely on fairly deep recursion, actually using a cache seems better than using an arbitrary cutoff here. Having an impl which is large enough to trigger a cutoff instead of getting rejected noticeably impacts perf, so just using a cache in these cases seems better to me. Does not matter too much in the end, we only have to make sure we don't regress crates which don't recurse deeply. [^1]: i've incremented a counter in the place I now call `if cache.get(&(lhs, rhs))` and then printed it on drop r? `@compiler-errors`

bors · 2024-11-29T18:47:05Z

☀️ Try build successful - checks-actions
Build commit: 2b0fb20 (2b0fb2074e35f4db7874c492fc119e608473f534)

rust-timer · 2024-11-29T20:05:05Z

Finished benchmarking commit (2b0fb20): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.7%]	13
Regressions ❌ (secondary)	0.3%	[0.2%, 0.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.5%	[-0.5%, -0.5%]	1
All ❌✅ (primary)	0.5%	[0.4%, 0.7%]	13

Max RSS (memory usage)

Results (secondary 4.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Cycles

Results (primary 4.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

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

Bootstrap: 772.629s -> 773.479s (0.11%)
Artifact size: 332.30 MiB -> 332.30 MiB (-0.00%)

compiler-errors · 2024-11-29T22:46:51Z

I think we need to eat this perf regression to make the trait solver feasible to land :>

r=me

lcnr · 2024-11-30T16:44:24Z

@bors r=compiler-errors rollup=never

bors · 2024-11-30T16:44:26Z

📌 Commit 3465ce5 has been approved by compiler-errors

It is now in the queue for this repository.

bors · 2024-12-02T09:19:23Z

⌛ Testing commit 3465ce5 with merge bd36e69...

bors · 2024-12-02T12:16:06Z

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing bd36e69 to master...

rust-timer · 2024-12-02T13:33:29Z

Finished benchmarking commit (bd36e69): comparison URL.

Overall result: ❌ regressions - please read the text below

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

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.4%, 0.7%]	13
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.4%, 0.7%]	13

Max RSS (memory usage)

Results (primary 0.7%, secondary -4.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.8%	[-1.8%, -1.8%]	1
Improvements ✅ (secondary)	-4.4%	[-4.8%, -3.9%]	2
All ❌✅ (primary)	0.7%	[-1.8%, 3.1%]	2

Cycles

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

Binary size

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

Bootstrap: 768.592s -> 768.435s (-0.02%)
Artifact size: 332.14 MiB -> 332.18 MiB (0.01%)

lqd · 2024-12-02T15:05:02Z

Only a small regression, multiple strategies were tried here and in other PRs to get to this result — and it's a necessary hit.

I think we need to eat this perf regression to make the trait solver feasible to land

from #133566 (comment)

@rustbot label: +perf-regression-triaged

rustbot assigned compiler-errors Nov 28, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 28, 2024

This comment has been minimized.

Sign in to view

rustbot added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Nov 28, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 28, 2024

Auto merge of rust-lang#133566 - lcnr:fast-reject-perf, r=<try>

96e2f40

fast-reject: add counter to avoid hangs alternative approach to rust-lang#133524 r? `@compiler-errors`

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Nov 28, 2024

oli-obk reviewed Nov 29, 2024

View reviewed changes

lcnr force-pushed the fast-reject-perf branch 2 times, most recently from 39841a4 to f6f4396 Compare November 29, 2024 09:49

lcnr changed the title ~~fast-reject: add counter to avoid hangs~~ fast-reject: add counter to avoid hangscache Nov 29, 2024

lcnr changed the title ~~fast-reject: add counter to avoid hangscache~~ fast-reject: add cache Nov 29, 2024

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 29, 2024

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 Nov 29, 2024

lcnr force-pushed the fast-reject-perf branch from f6f4396 to d2c948f Compare November 29, 2024 16:23

lcnr mentioned this pull request Nov 29, 2024

[DO NOT MERGE] bootstrap with -Znext-solver=globally #133502

Draft

lcnr force-pushed the fast-reject-perf branch from 0dc67dc to 59afc76 Compare November 29, 2024 17:00

lcnr mentioned this pull request Nov 29, 2024

Cache in DeepRejectCtxt #133524

Closed

fast reject: limit recursion depth

3465ce5

lcnr force-pushed the fast-reject-perf branch from 59afc76 to 3465ce5 Compare November 29, 2024 17:01

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 Nov 29, 2024

bors 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 Nov 30, 2024

bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 2, 2024

bors merged commit bd36e69 into rust-lang:master Dec 2, 2024
7 checks passed

rustbot added this to the 1.85.0 milestone Dec 2, 2024

lcnr changed the title ~~fast-reject: add cache~~ fast-reject: add depth check Dec 2, 2024

lcnr deleted the fast-reject-perf branch December 2, 2024 14:02

rustbot added the perf-regression-triaged The performance regression has been triaged. label Dec 2, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fast-reject: add depth check #133566

fast-reject: add depth check #133566

lcnr commented Nov 28, 2024 •

edited

Loading

lcnr commented Nov 28, 2024

This comment has been minimized.

bors commented Nov 28, 2024

bors commented Nov 28, 2024

This comment has been minimized.

compiler-errors commented Nov 28, 2024

rust-timer commented Nov 28, 2024

oli-obk Nov 29, 2024 •

edited

Loading

lcnr Nov 29, 2024

oli-obk Nov 29, 2024

lcnr commented Nov 29, 2024

This comment has been minimized.

bors commented Nov 29, 2024

bors commented Nov 29, 2024

This comment has been minimized.

rust-timer commented Nov 29, 2024

bors commented Nov 29, 2024

lcnr commented Nov 29, 2024

This comment has been minimized.

bors commented Nov 29, 2024

bors commented Nov 29, 2024

This comment has been minimized.

rust-timer commented Nov 29, 2024

compiler-errors commented Nov 29, 2024

lcnr commented Nov 30, 2024

bors commented Nov 30, 2024

bors commented Dec 2, 2024

bors commented Dec 2, 2024

rust-timer commented Dec 2, 2024

lqd commented Dec 2, 2024

fast-reject: add depth check #133566

fast-reject: add depth check #133566

Conversation

lcnr commented Nov 28, 2024 • edited Loading

Footnotes

lcnr commented Nov 28, 2024

This comment has been minimized.

bors commented Nov 28, 2024

bors commented Nov 28, 2024

This comment has been minimized.

compiler-errors commented Nov 28, 2024

rust-timer commented Nov 28, 2024

Overall result: ❌ regressions - please read the text below

oli-obk Nov 29, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lcnr commented Nov 29, 2024

This comment has been minimized.

bors commented Nov 29, 2024

bors commented Nov 29, 2024

This comment has been minimized.

rust-timer commented Nov 29, 2024

Overall result: ❌ regressions - please read the text below

bors commented Nov 29, 2024

lcnr commented Nov 29, 2024

This comment has been minimized.

bors commented Nov 29, 2024

bors commented Nov 29, 2024

This comment has been minimized.

rust-timer commented Nov 29, 2024

Overall result: ❌✅ regressions and improvements - please read the text below

compiler-errors commented Nov 29, 2024

lcnr commented Nov 30, 2024

bors commented Nov 30, 2024

bors commented Dec 2, 2024

bors commented Dec 2, 2024

rust-timer commented Dec 2, 2024

Overall result: ❌ regressions - please read the text below

lqd commented Dec 2, 2024

lcnr commented Nov 28, 2024 •

edited

Loading

oli-obk Nov 29, 2024 •

edited

Loading