-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Reduce the amount of untracked state in TyCtxt -- Take 2 #85941
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 609c07e5216722be1655706bb77620c4b20dfffd with merge c092198bf63a05c1b2a7a273c62471ced18e3d23... |
☀️ Try build successful - checks-actions |
Queued c092198bf63a05c1b2a7a273c62471ced18e3d23 with parent 2f601ef, future comparison URL. |
Finished benchmarking try commit (c092198bf63a05c1b2a7a273c62471ced18e3d23): 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 |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 82d52a7d9e8f17d28a95794f1c5c4b0bec7ef01c with merge 4b9cc4f754d1397c1c39dcb1398f8d1d647bbf8d... |
☀️ Try build successful - checks-actions |
Queued 4b9cc4f754d1397c1c39dcb1398f8d1d647bbf8d with parent 595088d, future comparison URL. |
Finished benchmarking try commit (4b9cc4f754d1397c1c39dcb1398f8d1d647bbf8d): 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 |
@cjgillot: Are you planning to work on improving the performance further, or do you think it's okay as-is? Seeing as the regressions are small, and this is correctness-related, I think either option would be fine. |
@@ -932,9 +940,15 @@ impl<'hir> intravisit::Map<'hir> for Map<'hir> { | |||
pub(super) fn index_hir<'tcx>(tcx: TyCtxt<'tcx>, (): ()) -> &'tcx IndexedHir<'tcx> { | |||
let _prof_timer = tcx.sess.prof.generic_activity("build_hir_map"); | |||
|
|||
// We can access untracked state since we are an eval_always query. |
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 think it would be good to enforce this in a follow-up PR - for example, moving the 'untracked' fields behind methods, which debug-assert that we're in an eval_always
query.
Finished benchmarking try commit (3ee1084b77128fa4b2b0232a3ed1aec844cf55c6): 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 |
The performance regressions are unfortunate - however, they're mostly small, and we were previously skipping necessary work. @michaelwoerister Does this look good to you? |
☔ The latest upstream changes (presumably #86695) made this pull request unmergeable. Please resolve the merge conflicts. |
I'll take a look shortly. |
☔ The latest upstream changes (presumably #86694) made this pull request unmergeable. Please resolve the merge conflicts. |
Yes, this looks correct to me. At some point I'd like to come up with a better argument than
You can either belief that or not I'm wondering if this interacts with rust-lang/compiler-team#437 (cc @jyn514). Regarding the performance regressions: removing the |
@michaelwoerister It would actually make it a good deal easier I think - it makes everything a lot more granular instead of needing access to the full definitions every time. Note that MCP still isn't accepted :/ and I'm not sure it will be until the resolver is tracked by incremental, which I think is still a long way off. |
r=me unless you want to try @michaelwoerister's suggestion of adding back |
Overall, I am more inclined to remove |
📌 Commit 9f6d7e7 has been approved by |
☀️ Test successful - checks-actions |
Main part of #85153
The offending line (#85153 (comment)) is replaced by a FIXME until the possible bug and the perf concern are both resolved.
r? @Aaron1011