You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would make sense to memoize the result of hashCode like you do in built_collection.
Is there any reason you do not? Would the performance gains be negligible? I'm not sure how expensive those bit-wise operations are in dart but it seems like it would be work memoizing, especially when using built_value with dart2js.
The text was updated successfully, but these errors were encountered:
Well, we'd have to measure to know the performance gains :) ... if you have a particular case in mind you could hack the .g.dart files yourself and try it.
You'd save the most time where you're using built_value for a large structure that does not rely on built_collection; for example if you're build a tree out of built_value Nodes. But, you'd also pay a lot for memory use.
The way Guava's @AutoValue does this is to allow you to redeclare hashCode as abstract then annotate to make it memoized.
It would make sense to memoize the result of hashCode like you do in built_collection.
Is there any reason you do not? Would the performance gains be negligible? I'm not sure how expensive those bit-wise operations are in dart but it seems like it would be work memoizing, especially when using built_value with dart2js.
The text was updated successfully, but these errors were encountered: