Thread by @SarahJamieLewis

Today I spent 5 hours debugging, and finally moved a single line of code up 10 lines.

Reduced cpu usage 20x.

Just want that on the record.

Basically: something that was supposed to get called once per app run, was getting called on every top-level UI rebuild, and because it updated one of the main global settings providers that update was also triggering a top level UI rebuild - so there was a rebuild cascade.

Moved the call out to where it actually belongs...no more rebuild cascade, all the consumers are now caching properly, all the render boundaries are kicking in and everything is now ridiculous fast.

It took so long to find because I was looking in the wrong place. CPU usage on the 1st pane of the app was pretty low, but increased significantly on the 2nd pane.

Assumed there was a bug there - but it was simply because the top level rebuild bug was more costly on pane 2.

The biggest clue should have been the performance dashboards showing constant rebuilds - but this bug had lain dormant for months so I didn't have a baseline for that being unusual (and there was a difference between pane 1 and pane 2 which did show up on the dashboard)

Now with the fix in place, the difference in the performance dashboard is obvious (there are no rebuild events when nothing happens). So we at least have a baseline now if a similar bug is introduced in the future.

The other compounding confusion was the generally correct advice that rebuilds are cheaper than repaints. And so a lot of the early debugging went into restricting repaints (using flutters repaint rainbow debugging tool).

But of course, regardless of how cheap you make everything and how much you restrict repaints, nothing survives a constant cascade.