-
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
Revert #43546 "save subobligations in the projection cache" #77325
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit cb7a9c6ac5b49777171397997012564810c86a14 with merge f1391937758145f22ee8b89aba5b57d9766029a6... |
// This is the hottest path in this function. | ||
// | ||
// If we find the value in the cache, then return it along | ||
// with the obligations that went along with it. Note | ||
// that, when using a fulfillment context, these | ||
// obligations could in principle be ignored: they have | ||
// already been registered when the cache entry was | ||
// created (and hence the new ones will quickly be | ||
// discarded as duplicated). But when doing trait | ||
// evaluation this is not the case, and dropping the trait | ||
// evaluations can causes ICEs (e.g., #43132). |
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.
Any reason you removed the comment too?
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 dropped it because I also removed the relevant code; that said, I think I deleted too much and some of them still serve as an explanation, so I will restore them later.
☀️ Try build successful - checks-actions, checks-azure |
Queued f1391937758145f22ee8b89aba5b57d9766029a6 with parent 48cab67, future comparison URL. |
Finished benchmarking try commit (f1391937758145f22ee8b89aba5b57d9766029a6): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Perf summary: improvements on deeply-nested, around -1% for certain (probably assoc-type heavy) cases, and no change for vast of the benchmarks. I'll continue to try to figure out what might break... |
0abd9d7
to
914ec15
Compare
I've concluded that the changes in UI test stderr can be justified, as it's not a recursive obligation but just a (unresolvable) self-reference, and such cyclic definitions are unlikely in real world use cases to warrant a specific diagnostic. I did some additional cleanup to fully revert the related changes. As for potential breakages, I feel it's unlikely to happen given all the tests are passing. Maybe we could get a crater run though. r? @nikomatsakis since you authored the original changes |
@ishitatsuyuki the primary motivation here is performance, or something else? |
The primary motivation is not performance, probably. I was looking at the
So then I spent some time figuring out why does this happen, and the result is this PR. The motivation is not that strong, I just wanted to get rid of these redundant log entries. |
☔ The latest upstream changes (presumably #73905) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
Status: get_paranoid_cache_value_obligation is gone with #73905 and I've got a real test failure now, so I need some time to figure out a fix (or to close this if I can't fix it). |
New discovery: a side effect of this PR is that #76179 would be fixed. I don't know if this is the only way to fix it, though. |
Looks like crater queue for this isn't correct. Both the older check and a newer "run" are queued. Should only be a new "check" |
@craterbot abort name=pr-77325 |
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@craterbot retry (just to ensure it's in the right state) |
🚨 Error: failed to parse the command 🆘 If you have any trouble with Crater please ping |
@jackh726 removed the older one now :) thanks |
We don't need a test, just a check @craterbot abort name=pr-77325-1 @craterbot check |
🗑️ Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
aah cool :) |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
It seems that this indeed introduces problems with trait resolution in some cases: Something similar happened when I updated the test cases, although all of them were compile-fail tests so I thought that fine and went with a bless. Turns out it isn't OK. I probably will close this PR, unless there turns out to be an easy enough solution to tackle the regressions above. |
Maybe we should see if #84944 suffers from the same problems as this PR |
This effectively reverts #43546 as it seems that it does affect performance more than the PR has anticipated.
This also removes the deduplication code from #48296 as duplications were primarily coming from #43546 and after removing that code it probably doesn't worth paying the cost of using a hash map.
Interestingly, the regression tests introduced in #43546 didn't fail after reverting, but some other tests had breakage. For now I just applied
--bless
, but I'd like to figure out if it could be a problem later on.Preliminary perf results confirms that we no longer need deduplication to avoid exponential behavior.
This PR will be draft until I figure out the potential breakage.
r? @ghost
Need a perf run. A crater run will help as well to identify potential breakage.