Skip to content
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

Merged
merged 2 commits into from
Dec 22, 2020

Conversation

tgnottingham
Copy link
Contributor

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.

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
Copy link
Collaborator

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 19, 2020
@tgnottingham
Copy link
Contributor Author

@rustbot label T-compiler A-incr-comp A-query-system I-compiletime

Pinging @Aaron1011, @michaelwoerister.

r? @Aaron1011

@rust-highfive rust-highfive assigned Aaron1011 and unassigned varkor Dec 19, 2020
@rustbot rustbot added A-incr-comp Area: Incremental compilation A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 19, 2020
@jyn514
Copy link
Member

jyn514 commented Dec 19, 2020

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion.

@bors
Copy link
Contributor

bors commented Dec 19, 2020

⌛ Trying commit 55ae3b3 with merge 705489d2220dba454392d2bdfce6f36ec6b757f7...

@bors
Copy link
Contributor

bors commented Dec 19, 2020

☀️ Try build successful - checks-actions
Build commit: 705489d2220dba454392d2bdfce6f36ec6b757f7 (705489d2220dba454392d2bdfce6f36ec6b757f7)

@rust-timer
Copy link
Collaborator

Queued 705489d2220dba454392d2bdfce6f36ec6b757f7 with parent 50a9097, future comparison URL.

@rustbot label: +S-waiting-on-perf

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 19, 2020
@rust-timer
Copy link
Collaborator

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 rollup- to bors.

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
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 19, 2020
@bjorn3
Copy link
Member

bjorn3 commented Dec 19, 2020

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
Copy link
Member

LGTM. @michaelwoerister Do you have any concerns about this approach? If not, r=me

@michaelwoerister
Copy link
Member

I'll take a look now.

@michaelwoerister
Copy link
Member

michaelwoerister commented Dec 22, 2020

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 DefPathTable encoding for crate metadata that allows for random access and basically free decoding (because everything is uncompressed). For that to really work we'll probably need a hashtable implementation that does not need decoding either -- which isn't rocket science but also isn't trivial. And we would need to switch DefPathHashes to being structured as mentioned in #79589 (comment). Putting all of those things together would make for a quite elegant setup, I think.

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
Copy link
Member

lqd commented Dec 22, 2020

CI is green, PR is reviewed, mw approves,🚀

@bors r=Aaron1011

@bors
Copy link
Contributor

bors commented Dec 22, 2020

📌 Commit 55ae3b3 has been approved by Aaron1011

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 22, 2020
@bors
Copy link
Contributor

bors commented Dec 22, 2020

⌛ Testing commit 55ae3b3 with merge bb1fbbf...

@bors
Copy link
Contributor

bors commented Dec 22, 2020

☀️ Test successful - checks-actions
Approved by: Aaron1011
Pushing bb1fbbf to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 22, 2020
@bors bors merged commit bb1fbbf into rust-lang:master Dec 22, 2020
@rustbot rustbot added this to the 1.50.0 milestone Dec 22, 2020
@tgnottingham tgnottingham deleted the foreign_defpathhash_registration branch January 20, 2021 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) I-compiletime Issue: Problems and improvements with respect to compile times. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.