-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Only disable cache if predicate has opaques within it #132625
Conversation
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
…, r=<try> Only disable cache if predicate has opaques within it This is an alternative to rust-lang#132075. It doesn't totally fix the issue, for example: `lemmy` goes from 1:29 (on rust 1.81) to 9:53 (on nightly) to 4:07 (after this PR). But I think it's at least *more* sound than a total revert :/ vibes??? r? lcnr
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (26e9516): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking 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 @bors rollup=never Instruction countThis 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.
Max RSS (memory usage)Results (primary 1.2%, secondary -0.1%)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.
CyclesResults (primary -2.4%, secondary -4.6%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 780.214s -> 780.319s (0.01%) |
while this isn't entirely correct if an opaque is not directly referenced by the obligation but ends up being used, e.g. as the return type of an so r=me after updating the description + src to not just be |
would reverting #126024 cause issues on stable? (I ask because of the reported 4x-10x regressions to compilation times it caused) |
in theory the incorrect caching should be triggered a lot more easily when reverting #126024 compared to the approach in this PR. It should still be fairly hard to trigger. I do have an idea on how to hopefully fully fix the regression |
TypingMode::Analysis { defining_opaque_types } => defining_opaque_types.is_empty(), | ||
// HACK: hack | ||
TypingMode::Analysis { defining_opaque_types } => { | ||
defining_opaque_types.is_empty() || !pred.has_opaque_types() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given that we use can_use_global_caches
both on access and on write, could we change this to instead check that pred
does not contain an opaque from defining_opaque_types
, i.e. it only contains rigid opaque types
On stable pretty much the only time you observe opaque types in their defining scope it for recursive RPIT, so I expect the slowdown to be caused by this triggering for opaques we can't actually define rn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually tested that and it doesn't improve perf very much lol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah perf only goes from 4:07 to 4:04 when i implement a simple visitor to check if it contains an opaque in the defines list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah perf only goes from 4:07 to 4:04 when i implement a simple visitor to check if it contains an opaque in the defines list
that seems weird to me 🤔 what's causing the regression here, reuse between different MIR borrowck queries?
e6a1578
to
4779c16
Compare
TypingMode::Analysis { defining_opaque_types } => defining_opaque_types.is_empty(), | ||
// | ||
// HACK: This is still theoretically unsound. Goals can indirectly rely | ||
// on opaquesvin the defining scope, and it's easier to do so with TAIT. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// on opaquesvin the defining scope, and it's easier to do so with TAIT. | |
// on opaques in the defining scope, and it's easier to do so with TAIT. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meow
4779c16
to
4915373
Compare
@bors r=lcnr |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c07aa1e): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis 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.
Max RSS (memory usage)Results (primary 1.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.
CyclesResults (primary -2.4%, secondary -5.6%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 781.244s -> 780.618s (-0.08%) |
Beta and stable backports accepted as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle. Stable backport also approved, though we don't see this alone as a reason to open a dot release. @rustbot label +beta-accepted +stable-accepted |
[beta] backports - Use completion item indices instead of property matching rust-lang#132987, rust-lang/rust-analyzer#18503 - Reject raw lifetime followed by `'`, like regular lifetimes do rust-lang#132341 - Only disable cache if predicate has opaques within it rust-lang#132625 - rustdoc-search: case-sensitive only when capitals are used rust-lang#133043 r? cuviper
[beta] backports - Use completion item indices instead of property matching rust-lang#132987, rust-lang/rust-analyzer#18503 - Reject raw lifetime followed by `'`, like regular lifetimes do rust-lang#132341 - Only disable cache if predicate has opaques within it rust-lang#132625 - rustdoc-search: case-sensitive only when capitals are used rust-lang#133043 - (ci) Update macOS Xcode to 15 rust-lang#131570 r? cuviper
This is an alternative to #132075.
This refines the check implemented in #126024 to only disable the global cache if the predicate being considered has opaques in it. This is still theoretically unsound, since goals can indirectly rely on opaques in the defining scope, but we're much less likely to hit it.
It doesn't totally fix #132064: for example,
lemmy
goes from 1:29 (on rust 1.81) to 9:53 (on nightly) to 4:07 (after this PR). But I think it's at least more sound than a total revert :/r? lcnr