Uh oh!
There was an error while loading. Please reload this page.
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.
rust-highfive
commented
Dec 19, 2020
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
tgnottingham
commented
Dec 19, 2020
@rustbot label T-compiler A-incr-comp A-query-system I-compiletime Pinging @Aaron1011, @michaelwoerister. r? @Aaron1011 |
jyn514
commented
Dec 19, 2020
@bors try @rust-timer queue |
rust-timer
commented
Dec 19, 2020
Awaiting bors try build completion. |
bors
commented
Dec 19, 2020
⌛ Trying commit 55ae3b3 with merge 705489d2220dba454392d2bdfce6f36ec6b757f7... |
bors
commented
Dec 19, 2020
☀️ Try build successful - checks-actions |
rust-timer
commented
Dec 19, 2020
Queued 705489d2220dba454392d2bdfce6f36ec6b757f7 with parent 50a9097, future comparison URL. @rustbot label: +S-waiting-on-perf |
rust-timer
commented
Dec 19, 2020
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. 🎉 |
Aaron1011
commented
Dec 19, 2020
LGTM. @michaelwoerister Do you have any concerns about this approach? If not, r=me |
michaelwoerister
commented
Dec 22, 2020
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! |
lqd
commented
Dec 22, 2020
CI is green, PR is reviewed, mw approves,🚀 @bors r=Aaron1011 |
bors
commented
Dec 22, 2020
📌 Commit 55ae3b3 has been approved by |
bors
commented
Dec 22, 2020
bors
commented
Dec 22, 2020
☀️ 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.