imagefiltered_transform_animation_perf__timeline_summary 90th_percentile_frame_build_time_millis has climbed, now predominantly regressed...

[kf6gpe]

I've missed this one for the last few days, because it's drifted in and out of being red. It's pretty clear now looking at the history that it's regressed slightly:

It's difficult for me to pinpoint a single roll causing it. The first time it went red was in restoring it after a gap (#60415), but I don't think that's it; I rather prefer engine roll #60384, in which the benchmark was still green, but a jump from its predecessor.

I'm tentatively giving this to the engine team, and given that it's not a huge regression, assigning it a P2 for investigation.

[kf6gpe]

Aha! Interesting. average_frame_build_time_millis is also affected, and regressed at the same engine roll.

[zanderso]

/cc @flar @liyuqian for possible relation to flutter/engine#17175. Is this expected?

[flar]

Yes, this figure regressed slightly, but I haven't investigated why. For one thing it makes no sense because the engine changes should have no effect at all on the dart-level frame building.

It was associated with a much more significant improvement in the average rasterization times, though, so we should probably accept it since overall time per frame should have gone down. We lost about .3ms on the build, but gained about 10ms on the render. That's the much more significant outcome.

With respect to why this happened when nothing changed in the framework code - The only thing I can think of is that by rendering more frames (the missed frame count went down and we render every frame now rather than every other frame and a half) we are experiencing more memory churn than before and so we have more GC happening.

Let me run some timelines before/after the change and graph them and see if that shows any interesting phenomena and then I'll re-baseline accordingly if that sounds like a good plan.

[flar]

I've graphed the frames sorted by build duration and there is a bump towards the far end of the measurements taken from the build that caches the children. Note that the cached (newer) version drew 36 more frames than the uncached (older) version (597 rendered frames vs 561). The older uncached version also performed 4 IdleGC cycles whereas the newer cached version performed 6 IdleGC cycles - suggesting that memory strain might be a contributing factor. I didn't look to see how much memory pressure existed across the GC cycles, though.

[chinmaygarde]

This looks like a candidate for re-baselining.