This CL:
* Makes the standard filesystem more synchronous by default.
This makes reading files for normal compiles faster.
* Adds a more asynchronous version of `exists` and `readAsBytes`.
This potentially allows for reading files faster when in a context
where the files can actually be read in parallel. The client have
to make the choise though.
* Skips `Uri.base.resolveUri` when the uri has a scheme. This makes it
slightly faster in my tests, but does not remove any `.` and `..`.
Having those when having a scheme seems sort of weird though.
If this turns out to be a problem we can add it back.
* Re-orders what the standard filesystem checks in `exists` to assume files
which seems more likely to happen. This - for files - means less checks
and should make checking for existance faster. (This was noticed by Siggi).
Using the same measurement procedure as in
https://dart-review.googlesource.com/c/sdk/+/85442
timing how long fasta spends on *reading* files when compiling dart2js
(when compiling via the VM) I get a good speedup.
Note that the measurements are in microseconds:
Before this CL (run like `out/ReleaseX64/dart pkg/compiler/bin/dart2js.dart 2>&1 | grep "Read file (total)" | tail -n 1` 10 times):
Read file (total): 94678
Read file (total): 94232
Read file (total): 91726
Read file (total): 77472
Read file (total): 95582
Read file (total): 88113
Read file (total): 89245
Read file (total): 91575
Read file (total): 96291
Read file (total): 95730
With this CL (run like `out/ReleaseX64/dart pkg/compiler/bin/dart2js.dart 2>&1 | grep "Read file (total)" | tail -n 1` 10 times):
Read file (total): 68379
Read file (total): 69320
Read file (total): 72930
Read file (total): 69692
Read file (total): 68685
Read file (total): 73548
Read file (total): 64649
Read file (total): 71951
Read file (total): 73486
Read file (total): 70621
Difference at 95.0% confidence
-21138.3 +/- 4193
-23.111% +/- 4.5843%
(Student's t, pooled s = 4462.56)
Furthermore, using an internal benchmark (discussed in an email thread)
I get these numbers (note that the measurements are in milliseconds):
before:
4453
4249
4187
4190
4216
after:
2310
2379
2449
2467
2407
Difference at 95.0% confidence
-1856.6 +/- 131.443
-43.5924% +/- 3.08625%
(Student's t, pooled s = 90.1257)
Using the asynchronous versions of exists and readAsBytes and checking for
existance and reading in parallel on the same internal benchmark it gets to
1137
1185
1067
1089
1189
For completion, comparing to using "raw" `File` (again using the internal benchmark):
sequential standard
2377
2419
2485
2373
2431
sequential io_sync
2279
2182
2237
2312
2324
io_sync faster:
-150.2 +/- 76.3122
-6.21432% +/- 3.15731%
(Student's t, pooled s = 52.3245)
sequential standardasync
4865
4915
4753
5185
4760
sequential io_async
4746
4834
4989
4840
4891
No difference proven at 95.0% confidence
parallel standard
2526
2563
2652
2616
2685
parallel io_sync
2335
2184
2244
2341
2401
io_async faster
Difference at 95.0% confidence
-307.4 +/- 111.037
-11.785% +/- 4.25691%
(Student's t, pooled s = 76.1341)
parallel standardasync
1137
1185
1067
1089
1189
parallel io_async
1105
1088
1145
1048
1113
No difference proven at 95.0% confidence
TEST=Existing tests.
Change-Id: I8ba56ab0768df8672bcdb693782d3f1eec86b683
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/185101
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Gary Roumanis <grouma@google.com>
This CL adds a simple spell-checker, adds a spell-checking-phase to
messages_test to spell-check our messages, adds a new test that
spell-check our dart-code and fixes a lot of spelling mistakes / typos.
Change-Id: I8943a5bd67970e9a8a775251ae0aa97799eab097
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/112346
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The many different entrypoints to the CFE have repeatedly shown problems
with targets that do not support unevaluated constants being used
without providing an environment.
Making the targets opt-in to supporting unevaluated constants will
give the users of CFE early notice that CFE is used inconsistently
(as opposed to the backends failing when they happen to see an
UnevaluatedConstant node that they don't support).
Change-Id: I98c80df3a551823598e413e2895f5649f22f7c22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/110561
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The option is not used by any client at this time and removing it simplifies the
next stack of changes I'll be making on how we compose file systems.
I also don't believe we will necessarily add this back as an option, but instead
it might be that clients requriing hermeticity will provide a custom file system
that helps with that.
Change-Id: I401efb042920d234382b6c041b13d40ffae5c908
Reviewed-on: https://dart-review.googlesource.com/56462
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This includes Fasta, tools and observatory, so the checked-in SDK must
have the lower-case constants.
Change-Id: I8380ad041ad058f7d02ae19caccfecd434d13d75
Reviewed-on: https://dart-review.googlesource.com/50201
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
The d2fe-fasta-legacy benchmark (which uses fasta_perf) was correctly disabling
both strong-mode and inference, but the d2fe-ikg-*-legacy benchmarks were only
disabling strong-mode and leaving inference enabled.
This change refactors the code to ensure that they are disabled consistently in
both.
Change-Id: Id7edc54209c41d27f735c66fc82024f5bf95fd09
Reviewed-on: https://dart-review.googlesource.com/26820
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This CL deprecates the front-end API and moves it into src/api_prototype.
For now all usages have been updated to point to the new location,
but they should be updated to use custom-client invocations instead (e.g.
one specific way for DDC, another for dart2js etc.)
Bug:
Change-Id: I9b4f41f6ebf55d42510fd35240d942d1dc7292d6
Reviewed-on: https://dart-review.googlesource.com/24822
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Kevin Millikin <kmillikin@google.com>
This just makes the name more appropriate since now that the default incremental
generator is not using kernel-driver altogether.
Change-Id: Ic7357dbb4eaad482f20249dd13ba3a49a39322d3
Reviewed-on: https://dart-review.googlesource.com/22160
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
This lets us benchmark separately:
- IKG implementations (the default based on kernel-driver or the minimal implementation)
- strong and non-strong mode
This also adds commands to try_benchmarks that highlight how these options will be used.
Change-Id: I5ce2c4563b7e79c33d78df7fd87be76f5d47e3f4
Reviewed-on: https://dart-review.googlesource.com/21320
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This CL replaces outdated VmTarget and FlutterTarget with VmFastaTarget
and FlutterFastaTarget. 'Fasta' suffix is droped from target names.
The new FlutterTarget extends VmTarget, so they share more code.
Change-Id: Id79956698a889c9a49b8a67914f1f96a731407ab
Reviewed-on: https://dart-review.googlesource.com/9423
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
generator.
The script takes an input program Uri, and a file describing edits, and it mocks
applying the edits in multiple iterations.
incremental_perf_test illustrates how this can be used to do incremental
compiles of the dart2js source code.
Change-Id: I3518996a0faac34de8c6cef2f63468f4788b3c06
Reviewed-on: https://dart-review.googlesource.com/6026
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Jens Johansen