For those who have missed this on Twitter
Follow up tweet
I thought I’d share here in case others want to weigh in with their thoughts
3 Likes
I would also add this reaction. Not saying that I agree or disagree with either, but just so it’s here as a opposing voice.
4 Likes
Great idea to have the opposing voice here!
Also I wonder if the 22fps were not a sign of very unnecessary rebuilds of too much of the UI.
We didn’t need any such hand optimization and our app does not suffer from feeling sluggish in any way.
In general the old rule still holds. Before you start optimizing measure what’s really going on.
2 Likes
Before anything, post your analysis_options.yaml and your Problems VSCode panel. =P
It’s very easy to fuck up Flutter (especially not using const constructors), so…
The author of that hack seems to know what he’s talking about - but he obviously had some valid reasons for needing to cache widgets vs standard optimisation.
Most developers should focus on making sure their widget tree is not rebuilding needlessly.
2 Likes
Another interesting tweet about it x.com
I’ve made an account specifically to note for the record that caching widgets is completely 100% valid and there is nothing wrong with it. We even document it as an approach in the framework: flutter/packages/flutter/lib/src/widgets/framework.dart at master · flutter/flutter · GitHub . Fundamentally, this is even how const works - it essentially creates the widget once and stores it in a global table.
Any criticism of this approach that is rooted in an interpretation of the framework’s “intention” is not based in reality.
6 Likes
In that case why wouldn’t the framework do this internally? An equality based caching (to expand upon const that does this already).
The framework, const, and a widget cache all use identity checks. identity checks are used instead of equality because the latter is extremely slow in a tree structure. Since most widgets define their children as part of the configuration, checking equality is recursive. Identity checks by contrast are always a single comparison.
For example, if you equality check a column with 100 items, you must first check equality of all 100 items. Then if it’s not equal, recursing into each item and checking it for equality with each previous widget…and so on. Changing the framework to do this automatically would reduce the number of rebuilds at the cost of regressing performance across the board. Which defeats the entire purpose.
4 Likes
I suppose it can be a good trick to figure out which part of the widget tree is responsible for the longer rebuild times.
Isn’t it funny how some of big phrases of Flutter can become dogmas if repeated sufficiently many times?
Similar thing happened in the early days with the phrase “Everything is a widget” which obviously was not true. Here we can see that sometimes it’s not entirely valid to say “Let Flutter device when to rebuild a widget” – you can affect that as developer quite easily.
1 Like
I guess the old wisdom still holds true, don’t optimize without benchmarking first.
1.So only start to think about manual optimization like widget caching of you see Performance problems.
2. Find out where to optimize (would be a separate thread to collect tips on how do do that.)
2 Likes