I've sampled (eagerly) reading the VM platform, a compilation of
dart2js, a compilation of "flutter gallery" and a compilation of a big
internal app, and reordered switch cases accordingly.
I can't measure any difference in runtime, but have a hard time
thinking it's not better.
I've included the tool that does the sampling.
Change-Id: If61c5a95265229c238020264010553f281fec49c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267362
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When loading the sdk, a compilation of dart2js and a big internal app
without lazy loading (but with useGrowableLists: false though that
part shouldn't matter) I see these changes:
Loading the sdk: Saving ~1.17 MB Public and ~0.33 MB Private.
A total of ~1.5 MB.
Loading a compile of dart2js: Saving: ~7.0 MB Public and ~1.1 Private.
A total of ~8.1 MB.
Loading a compile of a big internal app: Saving ~74.7 MB Public and
~25.4 MB Private.
A total of ~100 MB.
Specifically, when loading a big internal app I see these changes:
Change, without lazy loading (and useGrowableLists: false):
Current memory: -122.88 MB
Peak memory: -92.16 MB
Heap: -102.4 MB / -92.16 MB
_PublicNames: -74.75 MB (2 mio+ fewer)
_PrivateNames: -25.4 MB (800,000+ fewer)
Change, with lazy loading (and useGrowableLists: false):
Current memory: +10.24 MB (yes, more).
Peak memory: +10.24 MB (yes, more).
Heap: +2.2 MB / +2.5 MB (yes, more)
_PublicNames: -0.76 MB (20,000+ fewer)
_PrivateNames: -11.3 KB (some hundred fewer)
Change-Id: I710d966aacf2ab184139a1fb7e65e12551e830ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266386
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Looking at only the amount of data used by interface types after
loading a dill completely (lazy loading disabled or everything read):
Loading the sdk: Saving ~3.3 MB.
Loading a compile of a simple flutter app: Saving: ~11.6 MB.
Loading a compile of dart2js: Saving: ~18.2 MB.
Testing on a big internal app I see savings of 200+MB.
In my tests it reduces the amount of interface types by a factor of between 7 and 12.
Looking at the VMs reported memory, peak memory and heap usage, without
lazy loading for the big internal app we're talking ~200 MB savings,
with lazy loading (without loading anything) we're generally
talking a ~10MB saving (process current an peak memory,
but where the heaps total capacity was ~4 MB bigger).
https://github.com/dart-lang/sdk/issues/50161
Change-Id: Ic6601e907fb3127694f54e0865fe7c5a7057d9f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266383
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This adds AbstractSuperMethodInvocation, AbstractSuperPropertyGet,
AbstractSuperPropertySet nodes which are to be used for super access
in mixin declaration.
These super accesses do not resolve to their statically bound target
but instead the interface target on the types in the 'on' clauses, and
need to be updated to the statically bound target upon mixin application.
This has lead backends to disregard the interface target provided by
the CFE and instead always compute targets for super accesses.
This change is a step towards creating a clear separation between the
two use cases, enabling a more precise handling of super accesses.
The new nodes are not created yet with this CL.
TEST=existing
Change-Id: I70ea9baf5b4b970b10cc72b7409633d270d57755
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/245168
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL moves the bounds checking into the TypeBuilder instead of
performing it from the outside on the computed DartType node.
This solves several problems:
1) Errors are now reported on the type in the code instead of the
declaration which holds the type.
2) Checking of type aliases (both function and nonfunction type
aliases) is now handled correctly in all cases. This achieved by
computed the aliased type (containing TypedefType nodes)
internally and performing the checking on this type, and only
convert the type into the unaliased version (without TypedefType
nodes) after checks have been performed. Previously this handled
through the FunctionType.typedefType property for function type
aliases and through and incomplete work-around for nonfunction
type aliases.
3) With 2) FunctionType.typedefType is no longer needed and is
removed.
TEST=general/bounds_*
Change-Id: I7653bca5ccb0ebf4b3553828a298d1ad918ef235
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/243722
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This change includes kernel-related changes:
* --compact-async option is added to kernel compilers (front-end
server and gen_kernel). This option disables desugaring of async
and await on kernel AST. Note that 'await for' is still desugared.
* File offset of the 'await' is now written for AwaitExpression nodes
in the kernel binaries (will be used for async stack traces).
* Async/async*/sync* functions and AwaitExpression nodes are supported
in TFA.
Design doc: go/compact-async-await.
TEST=ci
Issue: https://github.com/dart-lang/sdk/issues/48378
Change-Id: I4233086b7434bc48347f4220645b0be5f9133456
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241842
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The computation of default values on super parameters requires the
notion of a declared initializer. By adding this as a flag to
VariableDeclarations the implementation can now be normalized across
parameter from source and dill.
TEST=existing
Change-Id: Ic980e68b569e3bdab38d2c7c7e4374e0c931a87b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/240403
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL replaces most usages of `.from` (e.g.
`List<String>.from(variable)`) to use `.of` instead.
This is done because code like
`List<String> foo = new List<String>.from([null])`
is valid and gives no warnings or errors.
Using `.of` instead will give an error.
Also `.of` appears to be slightly faster.
Change-Id: I1b4327be228b77e6a3e9faa283f8ce64f0565608
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/228642
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The added field holds the interface signature type for a Procedure when
this is different from the class signature type (implied by the function
parameters and return type). This is needed for forwarding semi stubs
when its declared type is different from the called super member.
Closes https://github.com/dart-lang/sdk/issues/47072
TEST=pkg/front_end/testcases/general/implement_semi_stub.dart and more
Change-Id: I4a7cdc9d564fb0a59e7b06e83646b5410d8d82f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/216420
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <dmitryas@google.com>
This adds a third reference to Field declaration, so that we know have
three references, one for each use case:
1) fieldReference used for initialization; in FieldInitializer and as
the key in the InstanceConstant.fieldValues map.
2) getterReference used for reading; in InstanceGet, StaticGet and
SuperPropertyGet
3) setterReference used for writing; in InstanceSet, StaticSet and
SuperPropertySet
TEST=existing
Change-Id: I223f130e808e7f19a831c1fe5e3a4725d1bcdc3b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203770
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
In 3c83032c60
(https://dart-review.googlesource.com/c/sdk/+/195517)
a change inadvertently made it in that changed readAnnotationList from
always returning a constant empty list when the size was 0, to only
returning an (almost) constant list if the size was 0 and a non-default
setting was enabled.
In practise that meant that for normal runs we went from returning
a constant list when the size was 0 to returning a new empty list,
and the benchmarking system said
AstFromBinaryLazy (Intel Xeon): +33.2%
AstFromBinaryLazyP90 (Intel Core i5): +87.2%
AstFromBinaryLazyP90 (Intel Xeon): +117%
(i.e. generally much slower).
This CL restore the status quo and my local benchmarks says:
AstFromBinaryLazy(RunTimeRaw): -22.98% +/- 3.91%
AstFromBinaryLazyP50(RunTimeRaw): -6.20% +/- 5.03%
AstFromBinaryLazyP90(RunTimeRaw): -54.25% +/- 3.78%
Change-Id: Ia198cbbb0b2739f49a085435d98efb04740fa593
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/198280
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously constants were referenced via there relative binary offset,
i.e. a constant reference saying 42 meant at byte offset 42 relative to
the start of the constant table in the binary. This was done to be able
to (on the VM side) read the needed constants lazily. It meant, though,
that constants had to be stored in a map, mapping from the byte position
to the constant.
This change adds a level of indirection when needing the lazy reading,
but lets the constant references reference the constant number instead
so that a constant reference saying 42 means constant number 42,
i.e. constants can be stored in a list instead of in a map.
This is done on the dart side, but the VM still stores it in a map.
The level of indirection is a tabel next to the constant table where
each entry has constant size (4 bytes) from which one can read the
relative byte offset into the constant table from the constant number,
thus still being able to read needed constants lazily.
This CL also cleans up a leftover where for instance double constants
had their textual representation saved as a string in the string indexer
(and thus the output dill) even though they were never referenced.
File size changes:
* Platform: increses 7,816 bytes.
* Compile of dart2js (including platform): decreases 71,424 bytes.
Speed changes:
* Adding `UserTag`s to the code and looking at observatories cpu profile
on a `pkg/kernel/test/binary_bench.dart --golem AstFromBinaryLazy`
run of a compile of dart2js reading the constant table has gone
from ~10% to ~5%.
* Doing statistics on
`pkg/kernel/test/binary_bench.dart --raw AstFromBinaryLazy` run of a
compile of dart2js says -6.28169% +/- 4.97269%.
* Golem runs has nothing above the noise level.
It does say "AstFromBinaryLazy (Intel Xeon) -4.006% (0.4 noise)" and
"AstFromBinaryEagerP50 (Intel Core i5) -8.929% (0.6 noise)" though.
TEST=All tests running the VM tests this.
Change-Id: I07ead457527a4477de803ee55ba742f5557413d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/196925
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Kallen Tu