-
Couldn't load subscription status.
- Fork 13.9k
privacy: cache for trait ref in projection #146128
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
Conversation
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
privacy: cache for trait ref in projection
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (97bca8b): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @bors rollup=never Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 465.026s -> 467.402s (0.51%) |
|
r? @petrochenkov Could you have a look of this, Vadim? |
| let (trait_ref, assoc_args) = projection.trait_ref_and_own_args(tcx); | ||
| try_visit!(self.visit_trait(trait_ref)); | ||
| if self.visited_trait_ref_in_projection.insert(trait_ref) { | ||
| try_visit!(self.visit_trait(trait_ref)); |
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.
This is only correct to do if in all concrete DefIdVisitors visit_trait always does the same thing for the same trait_ref and that thing is not affected by mutable state in the visitor.
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.
TypePrivacyVisitor and SearchInterfaceForPrivateItemsVisitor clearly satisfy that condition by not having any mutable state, but I'm not so sure about ReachEverythingInTheInterfaceVisitor and ReachableContext.
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.
ReachEverythingInTheInterfaceVisitor and ReachableContext seem to also be idempotent.
|
Caching in this PR is overfit to one specific test case, #147486 (comment) shows that you can achieve the same effect in a more general way by caching all You could apply the changes from #147486 to this PR, or I can just land #147486 instead. |
|
Reminder, once the PR becomes ready for a review, use |
| <<Mask as TypeTupleAccess>::_5 as MaskBit>::Pick<Pick<5>>, | ||
| >; | ||
|
|
||
| fn main() {} |
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 don't think it makes sense to add this to UI tests, UI tests do not tests whether something compiles fast or slow, so it will mostly just slow down the testing.
It could potentially be added as a stress benchmark to https://github.com/rust-lang/rustc-perf though.
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.
It could potentially be added as a stress benchmark to https://github.com/rust-lang/rustc-perf though.
This example seems like a good fit for the secondary benchmark suite. 🤔
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.
The benchmark is currently too slow for rustc-perf, it takes ~25s just to check, and we run a lot of configs three times, so this would take many minutes to benchmark.
In case you didn't build this manually, but used some code generator, could you generate a faster version? E.g. with less items in the TypeTuple.
privacy: Introduce some caching to type visiting in `DefIdVisitorSkeleton` The caching fixes compilation speed issues in special cases like #145741, without introducing too much overhead in general cases. I tried to cache more, but it caused regressions from the caching overhead, like it can be seen from benchmark runs below. Inspired by #146128. Closes #145741.
privacy: Introduce some caching to type visiting in `DefIdVisitorSkeleton` The caching fixes compilation speed issues in special cases like rust-lang/rust#145741, without introducing too much overhead in general cases. I tried to cache more, but it caused regressions from the caching overhead, like it can be seen from benchmark runs below. Inspired by rust-lang/rust#146128. Closes rust-lang/rust#145741.
Fixes #145741
Performance test results from local for #145741:
I'm uncertain if this is a completely correct fix, as I've just reviewed the privacy update logic and it appears that a single update should suffice in the alias term. Feel free to close this if there are any algorithmic inaccuracies, and I'll investigate further.