-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Reduce the amount of untracked state in TyCtxt -- Take 2 #85941
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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