[BUG] 7.0.0 -> 7.0.1 performance regression about flutter_map HOT 3 OPEN

created reproducible example. it seems to be related to dynamic update, and creating full sets of new polygons each build

mootw@52c347d

there was some discussion and i think its important to note a few things:

• what things should trigger new state or modifying state. these checks need to be efficient (as in fast enough to be worth it over just rebuilding each time). in some cases it is OK to rebuild every time and not cache.

• I had to use UniqueKey() in my workflow after changing from 7.0.0 -> 7.0.1 to restore some of the performance (UniqueKey skips the didModify widget checks which rebuilds the entire state every time and caches it. but the cache is obviously never used.) this resulted in performance somewhere between 7.0.0 -> 7.0.1 without any changes to my code.

• I think this use case is fairly normal and a user could expect to change the values regularly. Im generally avoidant of micro-optimizations as they can often result in performance trade-offs that are not worth it OR might require strong documentation.

• how can we make the polygon/polyline widget build behavior consistent and expected. i believe that #1904 was created to help maintain consistent behavior (see #1894 which it fixed), however at a huge performance cost. I want to look at a way to maintain good/expected behavior without adding too many checks in the way.

from flutter_map.

https://pub.dev/packages/collection
^
use this for list equality

from flutter_map.

fast_immutable_collections could be interesting as well because it caches the hashCode of its list types.

from flutter_map.