-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Improve tracing #93086
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
Improve tracing #93086
Conversation
|
Errors are because I added properties to Placeholder / RenderCustomPaint so the tests that dump things got messed up. |
bb46f72 to
16b86bd
Compare
goderbauer
left a comment
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.
nit: analyzer task is complaining about some whitespace.
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.
nit (and not really related to this PR): name seems like an unfortunate naming choice for a parameter that contains a string like that...
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.
yeah, it's inherited from the superclass where it makes more sense.
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.
Is there a performance cost associated with including all this information? Will this make it harder to compare relative performance of two widget builds if one widget includes a lot of information and the other doesn't?
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, the performance overhead of this is "charged" to the overall "BUILD" task and not the individual widgets, so it shouldn't make those comparisons harder?
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.
It's charged to the parent widget.
My perspective was that we'd mostly given up on making these traces representative of actual time. The tracing alone dramatically skews the numbers. It does go rather against #93262 though.
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.
Can we put these extra arguments behind a flag then? While performance debugging customer:money it has been helpful to at least see relative performance differences between the individual widgets in the debugProfileBuildsEnabled mode to identify "slow widgets" (same for RenderObjects). As I said in #93262 I'd rather want make this mode faster than slower to make performance debugging even easier. Handling two traces (one with the extra profiling enabled and one without to get accurate numbers) has not been practical.
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.
There's already a flag: --profile. The arguments aren't added in profile builds. (In debug builds the traces aren't representative anyway because of JIT/AOT differences.)
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.
oh that said i see that i missed the case that you're commenting on, oops
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.
ah, it looks like i missed this in all the important cases. Somehow I remembered to protect it only in the rare cases.
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.
Why are these getting moved into _paintWithContext? Shouldn't a child that is a repaintBoundary have the cost of being one associated with them?
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.
Both codepaths go through _paintWithContext when they do work. Mostly I was trying to bring this closer to the code that actually calls paint(), because I couldn't understand how it worked (at first I thought that there was no paint tracing and so I added it to _paintWithContext because that felt like the logical place for it). Then I discovered actually we already had code there, but I didn't understand that it was always called, so I removed it in favour of the new location. I could have just left it in the old location, I think the effect is more or less the same.
Let me know if you prefer the old location.
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 old location feels a little more appropriate to me, but I don't feel super strongly about this.
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'll move it back
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.
oh, there is one code path that doesn't go through paintChild, though, and that's the flushPaints loop.
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.
Wondering if it is really useful to show the full path when this is enabled? It will make it look like as if every step is just contributing a tiny amount and it will also make it harder to spot this in traces.
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.
Showing the full path would be useful if one where to optimize the intrinsics calculations itself, but that seems rare?
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.
Mostly I was trying to show the depth of the tree being measured, just like we show the depth of the tree being built/laid out/painted.
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.
Makes sense. We can always turn this off in the future if it turns out to not be helpful.
16b86bd to
aa57e13
Compare
aa57e13 to
810b932
Compare
810b932 to
8103119
Compare
goderbauer
left a comment
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.
LGTM
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.
Move these inside the if (!kReleaseMode) {?
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.
good catch. fixed.
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.
Same here?
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.
done
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.
move this here as well?
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.
done
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.
Since the first version of this PR didn't do the "This data is omitted in profile builds.": Can we add a test to ensure that we don't regress this and accidentally include this in profile builds again?
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 ended up writing such a test by having test.dart compile an app in profile mode and then examining the build output for strings that would indicate that the method was incorrectly compiled in. I'm not 100% proud of the result, but it does seem to do what you want. :-)
75e6286 to
76af3df
Compare
goderbauer
left a comment
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.
Still LGTM, but some checks appear unhappy now.
28441a3 to
bbef6f5
Compare
.ci.yaml
Outdated
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.
ci.yaml looks good to me. Please ping me when you land this as infra will need to manually roll this to flutter/infra as the bot is broken (#93225)
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.
FYI #93225 is fixed, and this is safe to land yourself (no infra intervention required)
bbef6f5 to
c2bf33f
Compare
|
I don't understand why the LUCI presubmits aren't working anymore. |
568f58f to
caebfec
Compare
Outside of 9 AM - 5 PM PST on weekdays, there's a smaller infra pool and it takes longer for PR checks to be processed. It looks like they all got run, but if that was not the case let me know. |
1bffdad to
8be032e
Compare
12813a4 to
13c290e
Compare
35a5d0c to
fd34a62
Compare
fd34a62 to
7ff993a
Compare
* Add a test for tracing the framework. * Add a `DiagnosticsNode.toTimelineArguments()` that can be used easily with `Timeline.startSync`. * Rename some of the timeline events for clarity: hot reload dirtying now says "Hot Reload" for example, and the phases are in all caps (BUILD, LAYOUT, etc). * Always flag intrinsic and dry layout logic in debug and profile builds. Normally this only flags one event; when `debugProfileLayoutsEnabled` is true it shows the entire path. Might be good to have this flagged in the DevTools. Fixes flutter#93031. * Fix a broken link by pointing to our official documentation instead of Fuchsia documentation. Fixes flutter#92044. * Change how painting is traced when `debugProfilePaintsEnabled` is on to be more comprehensive. * Add some details to the top-level timeline events, e.g. what nodes are dirty, when the relevant `debugProfile*Enabled` flags are on. * Include the Diagnosticable information about a `RenderObject` or a `Widget` in the information logged when `debugProfileLayoutsEnabled`, `debugProfilePaintsEnabled`, or `debugProfileBuildsEnabled` are on. Fixes flutter#93009 * Refactor how tracing is done in the widgets library so that `RenderObjectWidget`s are included in the timeline when `debugProfileBuildsEnabled` is on. Fixes flutter#93007. Also: * Fix a minor error we introduced with the null safety migration: `DiagnosticsNode.toDescription` should return non-null. (Most of the logic either assumed that or already enforced it.) * Implement `debugFillProperties` for `Placeholder` and `RenderCustomPaint`, to help with the tests that were added. * Remove a TODO in `objects.dart` that we're never going to get to. * Improve some docs on `BuildContext`. * Cache `_dirtyElements[index]` in `buildScope`. * Improve docs for `operator ==` on `Widget`. Fixes flutter#49490. * Remove some code duplication in `framework.dart`. * Clean up `_NullWidget` a bit.
7ff993a to
c5993ae
Compare
|
FYI, no action needed. This PR reduced the stack size per nesting level: https://flutter-flutter-perf.skia.org/e/?begin=1634671383&end=1639497543&keys=Xe3d1bf0024fa24f0bb55e80af0d63e4e&requestType=0&xbaroffset=26844 |
|
I did fiddle with some "inline" calls in a few places, maybe that helped. |
DiagnosticsNode.toTimelineArguments()that can be used easily withTimeline.startSync.debugProfileLayoutsEnabledis true it shows the entire path. Might be good to have this flagged in the DevTools. Fixes Surface cost of intrinsics calculations in traces #93031.debugProfilePaintsEnabledis on to be more comprehensive.debugProfile*Enabledflags are on.RenderObjector aWidgetin the information logged whendebugProfileLayoutsEnabled,debugProfilePaintsEnabled, ordebugProfileBuildsEnabledare on. FixesdebugProfileBuildsEnabledand other equivalents should include arguments #93009RenderObjectWidgets are included in the timeline whendebugProfileBuildsEnabledis on. FixesdebugProfileBuildsEnableddoesn't show RenderObjectWidgets #93007.Timeline.startSynccalls with!kReleaseMode.Also:
DiagnosticsNode.toDescriptionshould return non-null. (Most of the logic either assumed that or already enforced it.)debugFillPropertiesforPlaceholderandRenderCustomPaint, to help with the tests that were added.objects.dartthat we're never going to get to.BuildContext._dirtyElements[index]inbuildScope.operator ==onWidget. Fixes Document whyWidget.operator==is marked as non-virtual #49490.framework.dart._NullWidgeta bit.