-
Notifications
You must be signed in to change notification settings - Fork 1.7k
More memory efficient use of List
s and Maps
s in the analyzer.
#49858
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
As some context: the CFE applied a similar change last year used for Dart2js. |
I'm not sure how you do these measurements, so I'm using a little expanded script that I used initially to get memory usage statistics for Before:
After:
The difference is almost entirely in Making I will review the CL in details and update / land it. |
@scheglov I see that @mkustermann CL/256843 as it was just a proof-of-concept, but you mention you may land something similar yourself? Do you know if you landed similar changes, or if this is still very much a pending item? |
The analyzer is a heavy user of
List
s andMap
s in the AST and the Element model.When running analyzer on flutter for 2 rounds (first warms up the memory store, second uses the cached outlines/... in memory store) the second round (after resolving all files) consumes around 470 MB. Out of that we have
=> We have 177 MB consumed by
List
/Map
(out of 470 MB in total), i.e. 37%.Growable lists in particular, they cost 32 bytes for the wrapper and the backing store is grown by 2x and therefore may often have unused space in them.
In almost all cases there's no need to use growable lists in the analyzer. All usages can be replaced by precise-length, non-growable lists. Furthermore, for empty lists, one should use a canonical representation of an empty list instead of having many empty list objects.
The top normal usages of growable lists in analyzer are
I've tried to see how much can be gained in cl/256843 and it seems to indicate at least 27 MB can be gained (21 MB removed growable lists, 6 MB in shorter non-growable lists).
The cl/256843 uses
const []
in place of empty lists. This is good for memory - though mixing different kinds of lists (e.g. const/non-growable/growable) causes polymorphism and therefore slower code.So my recommendation would be to enforce invariants: e.g.
InterfaceTypeImpl.typeArguments
will refer to a non-growable mutable list. That saves memory and will ensure access is not polymorphic./cc @scheglov @bwilkerson
The text was updated successfully, but these errors were encountered: