-
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
Don't perform any new queries while reading a query result on disk #91919
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 193372013836ac4e5940ebfe088bdd44cdcee7e5 with merge 535f5db4e39c1538a165cd4e32d36e737c439cfd... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
1933720
to
b9c6287
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit b9c62879fd4c4a31eb2fa8606dd0e2351dba51fd with merge 861c72a96000618f65e5a7f8cf224b77be30b4fc... |
☀️ Try build successful - checks-actions |
Queued 861c72a96000618f65e5a7f8cf224b77be30b4fc with parent 404c847, future comparison URL. |
Finished benchmarking commit (861c72a96000618f65e5a7f8cf224b77be30b4fc): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never |
Seems like an overall performance win, except for a few large outliers. |
The perf results are very similar to PR #91924 which was split out from this one, so I think that PR is responsible for all of the significant performance changes. |
let mut deps = TaskDeps::default(); | ||
deps.read_allowed = false; | ||
let deps = Lock::new(deps); | ||
K::with_deps(Some(&deps), op) |
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.
Should we prefer to use an enum for deps:
enum TaskDepsRef<'a> {
Allow(&'a Lock<TaskDeps>),
Ignore,
Forbid,
}
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.
Opened #92681
// are created during deserialization. See the docs of that method for more | ||
// details. | ||
let result = dep_graph | ||
.with_query_deserialization(|| query.try_load_from_disk(tcx, prev_dep_node_index)); |
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 think we can even forbid queries inside the invocation code. Can this call be moved around the NotYetStarted
branch of try_execute_query
? It's not supposed to invoke any user-provided code directly, only call into the DepGraph
to setup a TaskDeps
.
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 tried this earlier, but there are some invocations of def_span
within the query infrastructure itself. I think those could be removed in a follow-up PR, since this PR should catch almost all of the cases.
pub fn with_query_deserialization<OP, R>(&self, op: OP) -> R | ||
where | ||
OP: FnOnce() -> R, | ||
{ |
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.
Should we add a fast path if the dep-graph is disabled?
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 should never be called, if the dep-graph is disabled, right? Maybe we could add a debug assertion that the dep-graph is indeed enabled.
This looks good to me now. @cjgillot's comments make sense to me, but I'd be fine with addressing them at a later point in time. |
Let's get this merged. @bors r+ |
📌 Commit 27ed52c has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (a7e2e33): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
In addition to being very confusing, this can cause us to add dep node edges between two queries that would not otherwise have an edge.
We now panic if any new dep node edges are created during the deserialization of a query result. This requires serializing the full
AdtDef
to disk, instead of just serializing theDefId
and invoking theadt_def
query during deserialization.I'll probably split this up into several smaller PRs for perf runs.