-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Represent diagnostic side effects as dep nodes #122156
Conversation
Performance impact:
|
☔ The latest upstream changes (presumably #122227) made this pull request unmergeable. Please resolve the merge conflicts. |
Thanks for the ping, @Zoxc! I'll try to take a closer look some time this week. |
The changes1 look good to me. I like how this remove state from the context 🙂 One question: does this increase the number of dep-nodes we create? I can't quite tell if this will unconditionally emit a Footnotes
|
Looks like it will be one dep-node per emitted diagnostic, so that's fine. |
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.
Thanks @Zoxc! I like a lot how this design simplifies this whole side-effect tracking business.
Could you run perf on the rebased PR?
Could we do without having to thread the SerializedDepNodeIndex
everywhere?
An quick idea I have would be some SideEffectIndex
: a sequential index returned by store_side_effects
, and put into the side-effect DepNode
's fingerprint part. We'd still have the information we need, encoded sequentially in the on-disk cache instead of a hash-map.
f0413f6
to
c6011a7
Compare
This can get a perf run now. |
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Represent diagnostic side effects as dep nodes This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index. Some implications of this: - Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that. - Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks. - Reusing a CGU will now emit diagnostics from the task generating it. Based on rust-lang#122070.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (b616195): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking 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 may lead to changes in compiler perf. @bors rollup=never Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 0.8%, secondary -4.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -1.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 780.09s -> 779.623s (-0.06%) |
I think something like that could work, less sure if it's an improvement though. |
c6011a7
to
9a847b1
Compare
@rustbot ready |
if let Some(ref data) = self.data { | ||
D::read_deps(|task_deps| match task_deps { | ||
TaskDepsRef::EvalAlways | TaskDepsRef::Ignore => return, | ||
TaskDepsRef::Forbid | TaskDepsRef::Allow(..) => { |
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.
Shouldn't Forbid be unreachable here? If we are decoding a query will we ever emit diagnostics?
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.
The forbid case will just panic in read_index
, so it's just a sanity check.
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 guess 😃
@bors r+ |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1aeb99d): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 1.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -1.6%, secondary -2.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 773.717s -> 774.586s (0.11%) |
This changes diagnostic to be tracked as a special dep node (
SideEffect
) instead of having a list of side effects associated with each dep node.SideEffect
is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a newSideEffect
with an unique dep node index.Some implications of this:
Diagnostic may now be emitted more than once as they can be emitted once when the
SideEffect
gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that.Anon tasks which emits diagnostics will no longer incorrectly be merged with other anon tasks.
Reusing a CGU will now emit diagnostics from the task generating it.