You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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`
0 commit comments