The Windows builder analyzer-win-release is waiting for shards
to complete after running the analysis server benchmarks, so we
can run the benchmarks twice to get more better results.
Bug: b/74375756
Change-Id: I03f459aece293a7e0b0eed3f4c52c037e2d9641c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290061
Reviewed-by: Alexander Thomas <athom@google.com>
- Adds a new flag, `--suppress-analytics` to the `dart` command to
disable both the unified and the legacy analytics for a single
session while deprecating the existing flag, `--[no-]analytics` used
for disabling the legacy analytics on a single pass.
- Pipelines the flag from `dart` through `dart analyze` and `dart fix`
to the execution of the analysis server.
- Updates all applicable uses of `dart analyze`, `dart fix`, and the
analysis_server binary entry points in the SDK to disable analytics
for the test infrastructure.
Bug: https://github.com/dart-lang/sdk/issues/49445
Change-Id: I1302cad7e04b21454aa7d9e8ee72a876b231377d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287661
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Janice Collins <jcollins@google.com>
* Add a type argument to raw `Future` types (typically `Future<void>`)
* Add type arguments to raw `Map` types (typically Map<String, Object?>`)
* Add a type argument to raw `Completer` constructor calls.
* Use collection-elements in more places.
* Replace an implementation of `String.padLeft` and `String.padRight` with
StringBuffer extension methods that use `String.padLeft` and
`String.padRight`.
* Rename many `sb` variables to `buffer`, which is more idiomatic.
* Move some StringBuffer helper methods to be extensions on StringBuffer.
* Use constructor tear-offs instead of closures which call a constructor.
* Use single quotes where we can.
* Do not prefix constant names with the letter 'k' [1].
* In IntegrationTestMixin:
* Rename to `IntegrationTest`, as it is never used as a mixin.
* Public Stream fields are converted to be getters.
* Private StreamController fields are initialized at their declaration [2],
instead of an initialization method.
* Remove empty zero-parameter constructors.
[1] https://dart.dev/guides/language/effective-dart/style#dont-use-prefix-letters
[2] https://dart.dev/guides/language/effective-dart/usage#do-initialize-fields-at-their-declaration-when-possible
Change-Id: I7a923a80d32f74fbecf42a0fa35ae25285994097
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281874
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
I am going to plumb some of this support through the flutter_tools
side, and want a consistent name for this port. 'servicePort' seems to
be more correct.
Change-Id: I73806e1d4c566a82605812504cb354c2b59710ea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280562
Auto-Submit: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL:
* Adds a benchmark of running `dart analyze` on a single small file.
* Adds a benchmark of running `dart analyze` on a single project.
* Adds a benchmark of running `dart analyze` on several projects.
* Adds a hidden flag to `dart analyze` so it reports ram usage:
run via `dart analyze --format=json --memory` and the memory
usage will be reported in the json output.
All the bencmarks run without and with cache for speed testing, and
without and with cache when measuring memory usage.
The idea of running this via `dart analyze` instead of running either
the script or the snapshot is to measure the "real world" speed which
could be different (although in practise it _does_ just run the
snapshot).
Future CL(s) should also add benchmarks for queries using the
language server.
Change-Id: Iad6d6d72c1a2ed18ab51d056b4914f8b6eb963e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/276100
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When I run
`out/ReleaseX64/dart-sdk/bin/dart pkg/analysis_server/benchmark/benchmarks.dart run analysis-server`
locally the process often doesn't finish because of a timing bug.
This fixes the one I'm running in to.
Change-Id: Ie94de8c4bb59211bff39ca2df1f8dd63fc53cc75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/270420
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
In an upcoming change some types will between these files. To reduce the size of that (already very large) CL and because the distinction between spec-generated/custom-generated types was unnecessary anyway, this adds a single import for LSP protocol-related types.
Change-Id: I322447d6c979538c12014d87875176e1bf2adca7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/244244
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We can change FlutterAnalyzeBenchmark because it is not actually
run now, the benchmarking framework calls `flutter analyze` directly.
This class is just FYI.
Flutter completion benchmarks are not used yet, so we can change
them as well.
Change-Id: I1426df572b6c37160076785f9a5a4b742ce36221
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
When running DAS from sources, so might be not exactly as when running
from the snapshot, currently we have following numbers:
Before reverting to allow available declarations:
{das-flutter-completion-start: {micros: 15030209}, das-flutter-completion-smallFile-body: {micros: 619210}, das-flutter-completion-smallFile-body-withoutPrefix: {micros: 484791}, das-flutter-completion-smallLibraryCycle-largeFile-smallBody: {micros: 2348386}, das-flutter-completion-mediumLibraryCycle-mediumFile-smallBody: {micros: 3701027}, das-flutter-completion-mediumLibraryCycle-mediumFile-api-parameterType: {micros: 3332297}}
Current 2021-09-30 master:
{das-flutter-completion-start: {micros: 15194069}, das-flutter-completion-smallFile-body: {micros: 22721}, das-flutter-completion-smallFile-body-withoutPrefix: {micros: 7796}, das-flutter-completion-smallLibraryCycle-largeFile-smallBody: {micros: 552269}, das-flutter-completion-mediumLibraryCycle-mediumFile-smallBody: {micros: 3076925}, das-flutter-completion-mediumLibraryCycle-mediumFile-api-parameterType: {micros: 3010509}}
Current 2021-10-01 master, with snapshot:
{das-flutter-completion-start: {micros: 6657503}, das-flutter-completion-smallFile-body: {micros: 20596}, das-flutter-completion-smallFile-body-withoutPrefix: {micros: 7073}, das-flutter-completion-smallLibraryCycle-largeFile-smallBody: {micros: 556415}, das-flutter-completion-mediumLibraryCycle-mediumFile-smallBody: {micros: 85024}, das-flutter-completion-mediumLibraryCycle-mediumFile-api-parameterType: {micros: 331850}}
Change-Id: I1d76f4f15d36e316b553ffc6cfaf24551c7f9bf5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/215240
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
When several isolates share same isolate group, they share the same heap.
This change iterates over isolate groups and aggregates their heap size instead of iterating over isolates.
Change-Id: I83b04110277b3a2d22ab758b50ee8c4ce480ea7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212382
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This should allow doing partial migration, specifically protocol files,
which are imported by other libraries, but are a small library cycle
that does not import much outside of it.
Change-Id: I904c05d6d5b444ee9a9dbd1f7ada12aabdcc5165
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/193583
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This is a reland of 604a366065
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
Change-Id: I917d3056322d74766bdf376a3e28871ad5b66cfa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147980
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit 604a366065.
Reason for revert: Breaks google3, see b/156414355
Original change's description:
> [ VM / DartDev ] Run all debugging sessions via 'dart run'
>
> Prior to this change, running `dart --observe foo.dart` would result in
> the DartDev flow being bypassed. While `dart foo.dart` will continue to
> bypass DartDev and be run directly, running either `dart --observe
> <vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
> will result in the command being implicitly converted to `dart run
> --observe <vm-flags> foo.dart`. This is required for all standalone VM
> instances to run against DDS instead of the VM service directly.
>
> As usual, the DartDev flow can always be bypassed by providing the
> --disable-dart-dev flag.
>
> Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I688a3779e7ccaf85a28dc4d6f5ccf23596109519
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147900
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
Prior to this change, running `dart --observe foo.dart` would result in
the DartDev flow being bypassed. While `dart foo.dart` will continue to
bypass DartDev and be run directly, running either `dart --observe
<vm-flags> foo.dart` or `dart --enable-vm-service <vm-flags> foo.dart`
will result in the command being implicitly converted to `dart run
--observe <vm-flags> foo.dart`. This is required for all standalone VM
instances to run against DDS instead of the VM service directly.
As usual, the DartDev flow can always be bypassed by providing the
--disable-dart-dev flag.
Change-Id: I211cd1ec4b1ec0e75ae0a568a66f1a0fc7b3852f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/147342
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Sam Rawlins