While investigating AOT compilation time it could be useful to
understand which members were analyzed the most in TFA.
This change adds "global.type.flow.print.timings" environment flag to
measure and show top TFA summaries (roughly correspond to members)
which were analyzed most number of times and which took the most
time to analyze.
TEST=manual testing
Issue https://github.com/dart-lang/sdk/issues/42442
Change-Id: I07d3253d1e6eb390074b7edf7c21686124a938d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179600
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
In certain cases involving auto-generated Dart sources there could be a
huge number of allocated classes which are subtypes of a certain class.
Specializing such cone types to set types, as well as intersection and
union operations on such types may be slow and may severely affect
compilation time. Also, gradually discovering allocated classes in
such cone types may cause a lot of invalidations during analysis.
In order to avoid servere degradation of compilation time in such case,
this change adds WideConeType which works like a ConeType when number of
allocated classes is large, but it doesn't specialize to a SetType and
has more efficient but approximate implementation of union and
intersection.
Uncompressed size of Flutter gallery AOT snapshot (android/arm64):
WideConeType approximation for types with
>32 allocated subtypes: +0.1176%
>64 allocated subtypes: +0.0956%
>128 allocated subtypes: +0.0027%
For now conservative approximation is used when number of allocated
types >128.
TFA time of large app #1: 175s -> 119s (-32%)
TFA time of large app #2: 211s -> 81s (-61.6%)
Snapshot size changes are insignificant.
TEST=Stress tested on precomp bots with
maxAllocatedTypesInSetSpecializations = 3 and 0.
Issue: https://github.com/dart-lang/sdk/issues/42442
Issue: https://github.com/dart-lang/sdk/issues/43299
Change-Id: Idae33205ddda81714e4aeccc7ae292e0164be651
b/154155290, b/177498788, b/177497864
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179200
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Now that `MigrationCliRunner.shouldBeMigrated` has the correct
signature and internal clients no longer use
`MigrationCliRunner.shouldBeMigrated2`, we can remove
`MigrationCliRunner.shouldBeMigrated2`.
Change-Id: I33bdc78a603c859dd8bf1928f2dbc23233ae5e7c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178763
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The new implementation uses the same API as flow analysis. This
should allow us to significantly simplify the CFE and analyzer, by
dropping their implementations of legacy type promotion in favor of
the shared implementation.
This CL just introduces the new implementation and unit tests for it;
it does not integrate it with the analyzer or CFE. I will follow up
with a CL that does the integration.
Change-Id: Ie07b3b39604d6a022ad42f3ae6b648a317c8af28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179560
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This is non-breaking since `shouldBeMigrated` is unreferenced outside
the nnbd_migration package). Once this lands, we can switch clients
from overriding/calling `shouldBeMigrated2` back to `shouldBeMigrated`
and then eliminate `shouldBeMigrated2`.
Change-Id: I1235113bda6f7609de17ec05e7120b312f201536
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178762
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The only references that are promotable are references to variables,
however in the near future I'll be adding logic to flor analysis to
keep track of attempts to promote fields; this will require tracking
references to property gets as well as references to `this`, so we
need to start building up data structures to track those references.
Bug: https://github.com/dart-lang/sdk/issues/38773
Change-Id: I0e3fd44f580bb85db3e8f405675b66aa4069e455
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The `url` argument is changing from `Object`, accepting either `String`
or `Uri` at runtime, to `Uri` for better static help.
https://github.com/dart-lang/http/pull/507
- Switch to using `Uri` for requests. Where sensible push this type into
the signature of the surrounding method.
- Make some updated method private where they were unnecessarily public
which makes it harder to have confidence when looking for usages.
Rename a method with an unnecessary `get` name.
Change-Id: Ibf075741d6b9d292349b15f1dc84004981729aca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/179368
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This adds a new messages kind 'info' to the CFE for showing general
information during compilation. A 'configuration' options is added
to `CompilerOptions` for telling the CFE how it is run.
The configuration 'compile' is added for when the CFE is invoked to
produces an "executable" as when running `dart compile`. When
configuration is set, the CFE emits an info message about the
null safety compilation mode.
Support for `dart compile exe` and `dart compile js` is added in this
CL. Support for `dart compile kernel|app-jit|aot` is not included.
In response to https://github.com/dart-lang/sdk/issues/44234
TEST=pkg/dartdev/test/commands/compile_test.dart
Change-Id: I08f51e2a3f5ad4841c4d703bcd266b7afb63c7c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178982
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This consists of a few combined changes:
* support `@Native` on tests: This entails calling registerExtensions
on user code, but only when running on native tests (which are explicitly
added to an allow list).
* support for invoking external top-level methods also on native tests.
* support for running `applyExtension` later in tests. This is because
tests introduce the JavaScript definitions after the calls to
registerExtensions happen. Note: this wouldn't be necessary if we one
day change how tests are loaded (e.g. if we can load the JavaScript
portion of the test before the module compiled by dartdevc is loaded).
That would entail more infrastructure work and given that this is only
used for ~200 tests, it doesn't seem worthwhile at this time.
* ensure extension symbols are also stored in `dartx.*` from a native
test. This is to ensure dynamic calls are fully supported.
* changes to the dart2js runtime to ensure the test code can run in both
dartdevc and dart2js with the same API.
* one updated test: all native tests need to be updated and I'll follow
up with those, but the changes on this test are included in this CL to
illustrate how this all fits together.
After this change (and parent changes), you can now run:
./tools/test.py -m release -c dartdevk -r d8 dart2js/native/native_checked_arguments1_frog_test
Change-Id: I4c2615a80b0e7611aa6f57abaa55b4e03b42bfe4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/177180
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Bug: https://github.com/flutter/flutter/issues/73176
This reverts commit 825f56c6aa.
Both ddc and dart2js keep a set of native class names to make sure
@JS() classes don't conflict. Instead of processing native classes
for every component, this CL caches the set of native classes. This
should address the recompile time issues related to the original
revert.
Change-Id: If8028f0842440e8b9354bec9d7f72d0d42fcd8bd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/178926
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Konstantin Shcheglov