Guess what, I benchmarked Flutter state management libraries. The results are very much what you’d expect (i.e., it’s very anticlimactic).
2 Likes
That’s good, it means that the performance comes out of the project arhitecture and best practices which have the biggest impact.
Nice findings!
1 Like
I’m really curious where Randal’s bloc_signals sits in this though—combining BLoC’s event structure with Signals’ synchronous updates feels like a sweet spot!
Have you explored pairing different application architectures with different state management patterns, and benchmarked the results?
I’m afraid I’m not sure what you mean. Can you give me a couple of examples?
Have you built applications combining various architectures (MVVM, Clean Architecture, Feature-First, Layer-First) with different state management packages (BLoC, Provider, GetX, Riverpod, Signals) and benchmarked their performance?
Oh! I have not. I’d have to have a strong reason to believe that the different combinations would have different performance. (Building the combinations takes time, especially if one wants to do it right, and also running the benchmark for many combinations in a statistically significant ways takes a lot of time — on the order of weeks if not months of continuous running.)
I’m open to suggestions if you have a reason to believe some combination(s) is going to have significantly better performance than others.
I don’t think this matters, the publish-subscribe is the same for all architectures. There are scenarios where imutability can kill the performance, like reallocating big collections, and some other quirks that are related to implementations that can trigger many rebuilds on expensive widgets.
2 Likes