-
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
rustc_query_system: explicitly register reused dep nodes #80177
rustc_query_system: explicitly register reused dep nodes #80177
Conversation
Register nodes that we've reused from the previous session explicitly with `OnDiskCache`. Previously, we relied on this happening as a side effect of accessing the nodes in the `PreviousDepGraph`. For the sake of performance and avoiding unintended side effects, register explictily.
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
@rustbot label T-compiler A-incr-comp A-query-system I-compiletime Pinging @Aaron1011, @michaelwoerister. r? @Aaron1011 |
@bors try @rust-timer queue |
Awaiting bors try build completion. |
⌛ Trying commit 55ae3b3 with merge 705489d2220dba454392d2bdfce6f36ec6b757f7... |
☀️ Try build successful - checks-actions |
Queued 705489d2220dba454392d2bdfce6f36ec6b757f7 with parent 50a9097, future comparison URL. @rustbot label: +S-waiting-on-perf |
Finished benchmarking try commit (705489d2220dba454392d2bdfce6f36ec6b757f7): 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 |
This doesn't have any effect on full and incr-full. (<0.1%) incr-unchanged and incr-patched got up to 2.4% faster with no regressions. 🎉 |
LGTM. @michaelwoerister Do you have any concerns about this approach? If not, r=me |
I'll take a look now. |
The approach looks good to me. It's similar to how we do "cache promotion" where we explicitly move things from the previous cache into the current one so things don't get lost. In general I'd would be happy if we could simplify this whole system so we don't need so much mutable state (and therefore always run into the risk of not doing things in the right order or just making things too complicated to understand). I envision a But all of that can be done at a later point in time (if it actually turns out to be a good idea 😃) Thanks for the PR, @tgnottingham and thanks for keeping an eye on this, @Aaron1011! |
CI is green, PR is reviewed, mw approves,🚀 @bors r=Aaron1011 |
📌 Commit 55ae3b3 has been approved by |
☀️ Test successful - checks-actions |
Register nodes that we've reused from the previous session explicitly
with
OnDiskCache
. Previously, we relied on this happening as a sideeffect of accessing the nodes in the
PreviousDepGraph
. For the sake ofperformance and avoiding unintended side effects, register explictily.