-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Remove CACHE_KEY global #80987
Remove CACHE_KEY global #80987
Conversation
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 got as far as render
and ran out of time.
I see a lot of changes adding the cache to print()
- why was it needed? I had a hard time finding it in all the changes.
Because we need the cache for both |
The job Click to see the possible cause of the failure (guessed by this bot)
|
And fixed! I wonder about the performance impact here though... Let's see. @bors try @rust-timer queue |
Awaiting bors try build completion. |
⌛ Trying commit d128d8c0521603d0728e95332b345e02478c4371 with merge debe71105b9f695cc73e8fa32554977127b531cf... |
☀️ Try build successful - checks-actions |
Queued debe71105b9f695cc73e8fa32554977127b531cf with parent 9bc8b00, future comparison URL. @rustbot label: +S-waiting-on-perf |
Finished benchmarking try commit (debe71105b9f695cc73e8fa32554977127b531cf): 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 |
No difference (or too little to be seen). |
This is not true - script-servo went up by about .5% of the total. The docs for Cache say:
So I expect most of the slowdown is because there's so many more places the cache is used. I think the only place you actually need it is for Before doing that, though, it's very strange to me that you need to pass a dummy cache in places. We discussed on discord that without that change, rustdoc starts showing impls in the wrong place, like Maybe it would be easier if you separate primitives from the cache structure, and kept primitive types as a thread-local, while moving everything else to DocContext? I think that would still allow your changes in #80883 without needing a |
I don't see how it could change anything, we're passing a reference, not by move. Also, this is at the very bottom of call stack, meaning that we'd have
No, it's an exact replica of how it currently works: we switch the empty cache with a filled one after running
I think it'd be much better to not have any globals. In that regard, even though we have an extra parameter in a lot of places, it's at least a lot more clear. Once again: it allowed us to see that the cache was used in multiple places and that it needed to not be filled in some cases. |
b158d00
to
c01ca8e
Compare
Updated! |
☔ The latest upstream changes (presumably #81057) made this pull request unmergeable. Please resolve the merge conflicts. |
c01ca8e
to
847f66b
Compare
Rebased. |
☔ The latest upstream changes (presumably #81240) made this pull request unmergeable. Please resolve the merge conflicts. |
847f66b
to
8cdbd95
Compare
Fixed conflicts. |
2c8bf62
to
d78e1ed
Compare
Let's give it anther try... And let's hope that if there is an error, we'll be able to see it this time. @bors: r=jyn514 |
📌 Commit d78e1ed has been approved by |
☀️ Test successful - checks-actions |
We realized in #80914 that the cache handling (through a global) needed to be updated to make it much easier to handle.
r? @jyn514