Generally the test loads a big dill thats 90+% the same content as the
previous load, then verifies it.
This CL loads smarter and verifies less.
Before this CL, locally, running
pkg/frontend_server/test/frontend_server_flutter.dart took
real 24m56.080s
user 48m42.422s
sys 1m2.360s
and the suite edition (using 4 shards in isolates) took
real 15m9.196s
user 53m41.118s
sys 1m30.045s
With this CL, locally running
pkg/frontend_server/test/frontend_server_flutter.dart takes
real 5m0.206s
user 9m23.933s
sys 0m20.984s
and the suite edition takes
real 3m24.243s
user 12m0.069s
sys 0m28.131s
On the try-bot the runtime seems to have gone from ~40 minutes
to ~20 minutes, the "compile flutter tests" step from ~30 minutes to
~10 minutes and the portion of time actually running the
dart-code that compiles, loads and verifies, from ~26 minutes
to ~7 minutes.
Change-Id: I6db225c33e1c0ee817f3880327e720446150ad7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347282
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
First of we apply the wanted lints etc we prefer.
This includes but isn't limited to using types (i.e. no "var") and
being explicit about creation (i.e. no missing "new").
Change-Id: I516bccdac9760221ea5311af4567466bb4a65c77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The test compiles a file, serializes it to disk, loads it from disk and
verifies it. There's more than 1500 compiles and they (at least some)
are up to something like 40 MB each meaning why might write something
like 60 GB (!) running this test.
As the data is only used in-process we can use `IOOverrides` to bybass
it actually saving to a file.
Change-Id: I4130d02c227ba6769d63482a499846a485aa5a3a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/322702
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When launched as a snapshot, the initial compile is slower than the existing pub approach because of a process start time of around 500 ms. When launched as a compiled executable, initial compile times are the same as the existing pub approach. Once launched, experimental results show times to produce a kernel file of at worst 1.5-2x faster than pub's solution and at best 10x faster than pub's solution. The typical workflow of making changes and recompiling results in an average of a 5x speedup with respect to pub's implementation.
Because compiler instances use a lot of memory, there is a limit on the number of active compilers that the resident server will keep alive, and will actively bring instances down when this limit is exceeded. If the user was previously compiling a given project during the lifespan of a ResidentFrontendServer and its compiler is taken down between requests, a new compiler instance will be allocated for the request. Performance is still between 1.5x-5x faster for this case when compared to pub's compile times.
Change-Id: If9ee1ecc71d660d34faf23381c764dc11d6a5902
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252001
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Michael Richards <msrichards@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
The test compiles tests from a flutter checkout, finding the packages
to find tests in, by finding .packages files. Now .packages files are
no longer generated and it doesn't find any packages and thus no tests.
This CL fixes this by instead looking for the new file.
Cq-Include-Trybots: luci.dart.try:flutter-frontend-try
Change-Id: I965435ae031c9f4887159fda1933b2ba0f9392b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/245001
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously there *could be* lots of failures caused by the compiler
auto-detecting nnbdmode (and as a consequence setting a specific nnbd
mode based on the first file compiled).
That means that the ordering of the files - which seems to be different
on the bot and on my local machine for instance - decides the nnbd mode
and as a consequence if there are errors because of it.
This CL splits compiles up into weak and strong and compiles those in
chunks, thus avoiding the errors.
Change-Id: If796458782fdbf4f7da4ebc98f6110f0279a12cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/201565
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Ignore a test that us web-only which the current setup doesn't
support.
Also fix a issue with how we answer configurable import questions ---
something that for now is untested (except that it makes a test work here).
Change-Id: Ic19858838c45f1d4ce718aae0f526b2f16f3e9d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/130365
Commit-Queue: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Auto-Submit: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
To support JavaScript compilation, the frontend_server will require a dependency on the dev_compiler. To avoid conflating this with the vm specific functionality, the frontend server will be split from its current location.
This change will require a small corresponding update in flutter/engine, documented in the patches directory
Change-Id: I47923765546f7f6fa43e36ef38f8f466d3a7b2fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/120321
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Alexander Markov