-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quadratic slowdown for lookup of bounds on associated types. #65510
Comments
Looking at a However, this explains why an individual query can reach 300ms, it's doing way more than I thought. EDIT: specifically for WF, it looks like EDIT2: disabling that part of WF gets me an overall 2.5x to 3x speedup on the stress test, and the only test failures appear to be less redundant error messages, not anything compiling when it shouldn't. EDIT3: the speedup for |
To explain more one of the places I believe the quadratic behavior is coming from:
|
In case another example is helpful as a stress test, or otherwise, I have a library that was very much affected by this issue. Before the linked commit, the library would take minutes to compile, after the refactor, which grouped trait bounds into marker traits, it took only a few seconds to compile: |
Assuming my initial approach (#66020) won't land, I've been looking for alternatives. Something that does appear to make a dent is making the trait selection/evaluation caches use
|
[WIP] [DO NOT MERGE] combine #66020 and #66821. That is, the two fixes for #65510, and only for perf testing purposes. The fact that they both work to a comparable extent, while touching different parts of the trait system, made me curious if there would be any gains from having both. r? @nikomatsakis
rustc: allow non-empty ParamEnv's in global trait select/eval caches. *Based on #66963* This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have). I'm opening this PR primarily to test the effects on perf. r? @nikomatsakis cc @rust-lang/wg-traits
rustc: allow non-empty ParamEnv's in global trait select/eval caches. *Based on #66963* This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have). I'm opening this PR primarily to test the effects on perf. r? @nikomatsakis cc @rust-lang/wg-traits
@eddyb this is the issue I was thinking of in @jonas-schievink's PR that interns the associated items, I think. |
Hmm I doubt that would make a big difference, as the problem is "baked into" The stress test even only has 2 associated types. |
Ah I see. The PR shouldn't affect this case since it only accelerates access to assoc. items, not their bounds. |
Yes, sorry, I did not mean that as "that PR should fix this" -- I think I misremembered what this issue was talking about. |
#73905 will have a significant positive impact on this. |
There are two factors here, which we've spotted combined in the wild:
type X: ...;
bounds to the trait-level, i.e.:<_ as Foo>::X: Bar
inFoo
'swhere
clauses appears to be quadraticAnd here's our stress test - apologies for the macro, but it takes a lot to push it into multiple seconds (the version in the wild had more sophisticated, and actually useful, macros):
Using
-Zself-profile
andsummarize
, we get this (times are total "self" times):00
-19
)00
-39
)type_op_prove_predicate
typeck_tables_of
check_item_well_formed
cc @rust-lang/wg-traits
The text was updated successfully, but these errors were encountered: