-
-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize collection ==/hashCode for when they do not need a "DeepCollectionEquality" #626
Comments
It should be possible to optimize the generated code based on the list type, yes. We still need to use DeepCollectionEquality for In particular, |
operator==
is terribly slow for lists - can we customize it? or change its implementation?
I am afraid no. Looking at its implementation, it calls
Maybe just copy-and-paste its implementation (~10 lines of code) to package |
Here is the compiler explorer: Example 1: only list ints (not realistic - since other code may use list of other types) Example 2: both list ints and list dynamics (If you want to show them side by side: https://godbolt.org/z/vnMjGxaPh) |
But why would edit: don't mind me, I got confused because apparently the code the docs shows is different from the one on package:collection's master branch (https://api.flutter.dev/flutter/package-collection_collection/ListEquality/equals.html vs https://github.com/dart-lang/collection/blob/2bbb27bff8c4e48c27160160c3a2fdb9070ae303/lib/src/equality.dart#L171) |
Basically, I am worried whether Dart compiler is smart enough.
Anyway, if the Dart compiler is very smart there may be overcomeable, but I am not sure and may not assume that without evidence. P.S. The related code
and
|
Do you maybe want to raise a PR for this? I have other things to do, but this would be a valuable change. I'd be glad to review a PR |
I will do it when having time. Could you please provide some hints on where to change? |
It's within |
To add some more context to this, it might really be a worthwhile optimization to try to avoid DeepCollectionEquality when possible. It is ~5x slower than ListEquality() in simple cases, and has quadratic complexity when the collection is actually nested ( O(n^2) runtime, where n is the level of nesting in the collection). So, a JSON Map<String, dynamic> with nesting level of 3 in a freezed object already takes ~60x longer to compare using == than an optimized version. See this tracking issue: and benchmark that I wrote: And, as Jake Wharton puts it,
|
Hi thanks for the lib! However, I am using it for large arrays(
List<int>
, or more specifically,Uint8List
), and the following:generates:
After digging into
DeepCollectionEquality
, it delegates toListEquality
, and the core code for the latter is:As we all know, this is terribly slow. There are tons of method calls there, and the types are
dynamic
so it cannot know it is aint
in advance so has to do tons of work instead of a simpleint
equality check.Can we customize the generated
operator==
? Or, canfreezed
be improved, such that it useslistEquals
https://api.flutter.dev/flutter/foundation/listEquals.html instead? (That method is indeed about 10 lines of code, so it is even easy to copy-and-paste into freezed's library)The text was updated successfully, but these errors were encountered: