-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Consider if List<double> and possibly List<int> should be backed by dart:typed_data
#54503
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
Comments
Generally in favor of doing something like this. There's a few aspects I want to highlight
|
I'd recommend using an implicit approach (just ask for a Developers would then only need to make the choice explicitly in all the cases where there is a real trade-off. It should be possible for a lint to flag exactly those cases. The main question would be whether there are enough "consistent improvement" cases to justify this approach, and whether it's sufficiently easy to determine which cases are consistent improvements, and which ones are trade-offs. The justification would be that we already do such things (e.g., based on redirecting factory constructors), and also that there's no reason to omit an improvement if we know we can get it. |
I am not suggesting static handling - though maybe it was not clear from my proposal. Effectively I suggest: if (T == int) return ...
if (T == double) return ... In all factories. That being said, I realized that static handling has the benefit that it does not introduce result-type-polymorphism for
I like this (automatically making types small) - but it was a problem: it introduces result type polymorphism. Consider for example: final dataA = <int>[1, 2, 3];
final dataB = <int>[0xffff, 0xffff, 0xffff];
final input = c ? dataA : dataB;
use(input); // now polymorphic Uint8List | Uint16List. There is no way of reliably magically determining optimal storage size, so I would leave this out of scope. I think it would be better if we supported something like: final data = const <Uint8>[1, 2, 3]; // Uint8List This is not a valid program today (because it's type error to do this), which means it is actually possible to change language to allow this. |
Anther aspect I haven't mentioned above is other collection types. They are unnecessarily slow (**) when used with primitive types. For example sets: Analogous to above, there's also the (**) e.g. |
It's always surprising to users that
List<double>
has poor performance characteristics, because it uses boxed representation. We could consider changingList
factories to return different unboxed representation fordouble
and possibleint
lists, e.g.List<double>
simply returnsFloat64List
.List<double>
returns a (new type)_GrowableFloat64List
.Similarly
List<int>
will map toInt64List
and_GrowableInt64List
.As a benefit users would no longer be surprised by performance.
Draw backs:
List<T>
where we can't statically exclude possibility ofT
beingint
ordouble
become result-type-polymorphic.List<int>
memory size increases on 32-bit platforms and in compressed pointer mode.Alternatively we could consider a performance oriented lint which recommends
Float64List
whenever it sees aList<double>
because it is almost never correct to useList<double>
./cc @alexmarkov @mkustermann
The text was updated successfully, but these errors were encountered: