dart-lang/sdk
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity
113,742 Commits 2 Branches 0 Tags
tonycloud/dev
Commit Graph

27 Commits

Author SHA1 Message Date
Paul Berry afcfbbeba8 Migrate developer experience packages to new constructor decl syntax. 
(Part of https://github.com/dart-lang/sdk/issues/63288)

This change migrates the packages owned by the developer experience
team to use the new constructor declaration syntax, described in
https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md#abbreviations-of-in-body-constructor-declarations.

This change was performed in an automated fashion, by (a) bumping the
packages' SDK constraints to `3.13.0-0`, (b) enabling the lints
`unnecessary_type_name_in_constructor` and
`unnecessary_const_in_enum_constructor`, (c) fixing the resulting lint
failures using `dart fix`, and then (d) reformatting the affected
files.

To ease code review, I've reverted unrelated formatting changes.

Since this change requires bumping SDK constaints to `3.13.0-0`, it
was only performed on packages that are *not* published on
pub. (Packages that *are* published on pub should remain on lower
language versions until at least after the stable version of 3.13 is
released, so that we don't block users on the stable channel from
receiving updates to those packages.)

Change-Id: Ibb4daebafd239da58251e838ea6a3f336a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/505046
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
 2026-05-27 14:52:58 -07:00
Sam Rawlins 83b47a8333 DAS: rename constants to use lowerCamelCase 
Change-Id: If3f23ffc275171c67d0dc9cab3ee4abb7c5bc117
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461181
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
 2025-11-14 10:26:10 -08:00
Jens Johansen b1c6707027 [analysis server] Make LSP change request processing faster 
When processing a change request we have to construct the new content
for the changed file from the "diff" we receive. Before this CL we
calcualted a `LineInfo` to normally only use 1 entry in the list, then
calculated the new String, then calculated the new String once more.

This CL only gets the offset of the line we actually need (in what I
assume to be the normal case of only needing 1 line) and only calculates
the new string once for a reduction in processing time of about 50%.

For small files it probably wont matter much, but for bigger files it
will likely be noticeable.

To get the actual data in the benchmark this CL introduces `asJson` in
the timing pages, and picks out of the performance data the
"real number" for the change request. Turns out the overall number can
be very wrong because there's an async gap (where other stuff can be happening) between the calculation being done and the timing being
stopped.

Data:

Original -> Not doing the line starts:
Difference at 95.0% confidence
        -284.7 +/- 35.8987
        -33.0624% +/- 4.16893%
        (Student's t, pooled s = 38.2065)

Not doing the line starts -> also not doing the newContent calculation twice:
Difference at 95.0% confidence
        -207.2 +/- 31.3105
        -35.9473% +/- 5.43207%
        (Student's t, pooled s = 33.3233)

In total, i.e. from original -> this CL:
Difference at 95.0% confidence
        -491.9 +/- 34.8949
        -57.1246% +/- 4.05237%
        (Student's t, pooled s = 37.1383)


This is with a size of 16,000 in the benchmark, but the processing should be linear so the ~57% decrease should be valid overall - although naturally in raw numbers it's not going to cut of ~half a second per 25 change requests in smaller files.

Raw data:

```
Original:
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":830,"size 16000: peak virtual memory size (kb)":2473160,"size 16000: total program size (virtual) (kb)":2309328,"size 16000: peak resident set size (\"high water mark\") (kb)":540228,"size 16000: size of memory portions (rss) (kb)":373328}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":938,"size 16000: peak virtual memory size (kb)":2365488,"size 16000: total program size (virtual) (kb)":2306336,"size 16000: peak resident set size (\"high water mark\") (kb)":509212,"size 16000: size of memory portions (rss) (kb)":438796}
{"size 16000: Initial analysis (ms)":7,"size 16000: Processing time for 25 change requests (ms)":900,"size 16000: peak virtual memory size (kb)":2354420,"size 16000: total program size (virtual) (kb)":2300740,"size 16000: peak resident set size (\"high water mark\") (kb)":496768,"size 16000: size of memory portions (rss) (kb)":443892}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":803,"size 16000: peak virtual memory size (kb)":2296448,"size 16000: total program size (virtual) (kb)":2223740,"size 16000: peak resident set size (\"high water mark\") (kb)":503040,"size 16000: size of memory portions (rss) (kb)":431608}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":821,"size 16000: peak virtual memory size (kb)":2315888,"size 16000: total program size (virtual) (kb)":2158996,"size 16000: peak resident set size (\"high water mark\") (kb)":520212,"size 16000: size of memory portions (rss) (kb)":360704}
{"size 16000: Initial analysis (ms)":15,"size 16000: Processing time for 25 change requests (ms)":835,"size 16000: peak virtual memory size (kb)":2323752,"size 16000: total program size (virtual) (kb)":2215748,"size 16000: peak resident set size (\"high water mark\") (kb)":534380,"size 16000: size of memory portions (rss) (kb)":416532}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":848,"size 16000: peak virtual memory size (kb)":2349108,"size 16000: total program size (virtual) (kb)":2219696,"size 16000: peak resident set size (\"high water mark\") (kb)":469712,"size 16000: size of memory portions (rss) (kb)":361812}
{"size 16000: Initial analysis (ms)":7,"size 16000: Processing time for 25 change requests (ms)":870,"size 16000: peak virtual memory size (kb)":2288416,"size 16000: total program size (virtual) (kb)":2204484,"size 16000: peak resident set size (\"high water mark\") (kb)":486716,"size 16000: size of memory portions (rss) (kb)":396940}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":895,"size 16000: peak virtual memory size (kb)":2280008,"size 16000: total program size (virtual) (kb)":2188336,"size 16000: peak resident set size (\"high water mark\") (kb)":476664,"size 16000: size of memory portions (rss) (kb)":398232}
{"size 16000: Initial analysis (ms)":18,"size 16000: Processing time for 25 change requests (ms)":871,"size 16000: peak virtual memory size (kb)":2281128,"size 16000: total program size (virtual) (kb)":2216500,"size 16000: peak resident set size (\"high water mark\") (kb)":477080,"size 16000: size of memory portions (rss) (kb)":426856}

No line starts:
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":633,"size 16000: peak virtual memory size (kb)":2279560,"size 16000: total program size (virtual) (kb)":2169640,"size 16000: peak resident set size (\"high water mark\") (kb)":467740,"size 16000: size of memory portions (rss) (kb)":365508}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":578,"size 16000: peak virtual memory size (kb)":2481552,"size 16000: total program size (virtual) (kb)":2307804,"size 16000: peak resident set size (\"high water mark\") (kb)":547824,"size 16000: size of memory portions (rss) (kb)":370972}
{"size 16000: Initial analysis (ms)":6,"size 16000: Processing time for 25 change requests (ms)":568,"size 16000: peak virtual memory size (kb)":2412752,"size 16000: total program size (virtual) (kb)":2301564,"size 16000: peak resident set size (\"high water mark\") (kb)":546168,"size 16000: size of memory portions (rss) (kb)":447020}
{"size 16000: Initial analysis (ms)":5,"size 16000: Processing time for 25 change requests (ms)":530,"size 16000: peak virtual memory size (kb)":2426432,"size 16000: total program size (virtual) (kb)":2364240,"size 16000: peak resident set size (\"high water mark\") (kb)":565100,"size 16000: size of memory portions (rss) (kb)":503364}
{"size 16000: Initial analysis (ms)":12,"size 16000: Processing time for 25 change requests (ms)":620,"size 16000: peak virtual memory size (kb)":2276668,"size 16000: total program size (virtual) (kb)":2226296,"size 16000: peak resident set size (\"high water mark\") (kb)":477488,"size 16000: size of memory portions (rss) (kb)":434240}
{"size 16000: Initial analysis (ms)":12,"size 16000: Processing time for 25 change requests (ms)":534,"size 16000: peak virtual memory size (kb)":2391200,"size 16000: total program size (virtual) (kb)":2349392,"size 16000: peak resident set size (\"high water mark\") (kb)":531700,"size 16000: size of memory portions (rss) (kb)":490400}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":588,"size 16000: peak virtual memory size (kb)":2377112,"size 16000: total program size (virtual) (kb)":2278476,"size 16000: peak resident set size (\"high water mark\") (kb)":518740,"size 16000: size of memory portions (rss) (kb)":412952}
{"size 16000: Initial analysis (ms)":10,"size 16000: Processing time for 25 change requests (ms)":589,"size 16000: peak virtual memory size (kb)":2373204,"size 16000: total program size (virtual) (kb)":2258000,"size 16000: peak resident set size (\"high water mark\") (kb)":516188,"size 16000: size of memory portions (rss) (kb)":390972}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":583,"size 16000: peak virtual memory size (kb)":2349184,"size 16000: total program size (virtual) (kb)":2206488,"size 16000: peak resident set size (\"high water mark\") (kb)":555888,"size 16000: size of memory portions (rss) (kb)":404356}
{"size 16000: Initial analysis (ms)":9,"size 16000: Processing time for 25 change requests (ms)":541,"size 16000: peak virtual memory size (kb)":2335140,"size 16000: total program size (virtual) (kb)":2227132,"size 16000: peak resident set size (\"high water mark\") (kb)":540204,"size 16000: size of memory portions (rss) (kb)":433256}


Additionally don't do it twice:
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":379,"size 16000: peak virtual memory size (kb)":2274520,"size 16000: total program size (virtual) (kb)":2197944,"size 16000: peak resident set size (\"high water mark\") (kb)":470816,"size 16000: size of memory portions (rss) (kb)":393124}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":431,"size 16000: peak virtual memory size (kb)":2353820,"size 16000: total program size (virtual) (kb)":2287616,"size 16000: peak resident set size (\"high water mark\") (kb)":494148,"size 16000: size of memory portions (rss) (kb)":428836}
{"size 16000: Initial analysis (ms)":15,"size 16000: Processing time for 25 change requests (ms)":334,"size 16000: peak virtual memory size (kb)":2210904,"size 16000: total program size (virtual) (kb)":2164796,"size 16000: peak resident set size (\"high water mark\") (kb)":472180,"size 16000: size of memory portions (rss) (kb)":437368}
{"size 16000: Initial analysis (ms)":16,"size 16000: Processing time for 25 change requests (ms)":364,"size 16000: peak virtual memory size (kb)":2284260,"size 16000: total program size (virtual) (kb)":2239292,"size 16000: peak resident set size (\"high water mark\") (kb)":482420,"size 16000: size of memory portions (rss) (kb)":437232}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":397,"size 16000: peak virtual memory size (kb)":2148164,"size 16000: total program size (virtual) (kb)":2118072,"size 16000: peak resident set size (\"high water mark\") (kb)":479676,"size 16000: size of memory portions (rss) (kb)":446752}
{"size 16000: Initial analysis (ms)":5,"size 16000: Processing time for 25 change requests (ms)":327,"size 16000: peak virtual memory size (kb)":2292012,"size 16000: total program size (virtual) (kb)":2269972,"size 16000: peak resident set size (\"high water mark\") (kb)":487932,"size 16000: size of memory portions (rss) (kb)":476524}
{"size 16000: Initial analysis (ms)":8,"size 16000: Processing time for 25 change requests (ms)":339,"size 16000: peak virtual memory size (kb)":2348844,"size 16000: total program size (virtual) (kb)":2286660,"size 16000: peak resident set size (\"high water mark\") (kb)":484112,"size 16000: size of memory portions (rss) (kb)":432036}
{"size 16000: Initial analysis (ms)":16,"size 16000: Processing time for 25 change requests (ms)":393,"size 16000: peak virtual memory size (kb)":2277080,"size 16000: total program size (virtual) (kb)":2248636,"size 16000: peak resident set size (\"high water mark\") (kb)":472864,"size 16000: size of memory portions (rss) (kb)":440092}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":365,"size 16000: peak virtual memory size (kb)":2397828,"size 16000: total program size (virtual) (kb)":2201648,"size 16000: peak resident set size (\"high water mark\") (kb)":530176,"size 16000: size of memory portions (rss) (kb)":334264}
{"size 16000: Initial analysis (ms)":11,"size 16000: Processing time for 25 change requests (ms)":363,"size 16000: peak virtual memory size (kb)":2286312,"size 16000: total program size (virtual) (kb)":2253760,"size 16000: peak resident set size (\"high water mark\") (kb)":480004,"size 16000: size of memory portions (rss) (kb)":464720}
```

Change-Id: If122d4667da677fc07cab83ae97135d3a7ac99d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457722
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-10-29 02:05:35 -07:00
Jens Johansen 57412aa8f4 [analysis server] Add more benchmarks 
Change-Id: I8683effd68ac54c742c27cb7e6f5129e9e0b9a35
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/457363
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-10-27 06:20:13 -07:00
Jens Johansen 820a1ec5a5 [analysis server] Don't allocate on each compare when sorting in semanticTokens/full 
Upon a `textDocument/semanticTokens/full` request the analysis server
sorts the "tokens" via `sort` on List giving it a compare method.
The method, though, created a map literal for each comparison.
This CL "inlines" the map (it only had one entry anyway) and adds a
benchmark, where I note these changes:

```
1000:
Difference at 95.0% confidence
        -0.0274151 +/- 0.0135978
        -33.1981% +/- 16.4662%
        (Student's t, pooled s = 0.0181832)

2000:
Difference at 95.0% confidence
        -0.027344 +/- 0.0096196
        -20.9529% +/- 7.3712%
        (Student's t, pooled s = 0.0128635)

4000:
Difference at 95.0% confidence
        -0.108847 +/- 0.0196627
        -35.3172% +/- 6.37987%
        (Student's t, pooled s = 0.0262932)

8000:
Difference at 95.0% confidence
        -0.20647 +/- 0.0272577
        -34.4932% +/- 4.55371%
        (Student's t, pooled s = 0.0364494)

16000:
Difference at 95.0% confidence
        -0.384931 +/- 0.0401393
        -31.4809% +/- 3.28272%
        (Student's t, pooled s = 0.0536748)
```
Change-Id: Ibacce056cd3f154afc9377805bbccfd8c5ca9ea9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/456341
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-10-22 23:42:19 -07:00
Jens Johansen 1967fb2c40 [analysis_server] Add benchmark for missing end brace in string interpolation 
I found that in VSCode, if you have a pre-existing print, say

```
print("hello world");
```

if you then want to add a string interpolation right at the start of the
string, VSCode doesn't automatically insert the end brace and that
currently recoveres badly:

```
print("${whateverhello world");
```

This adds a benchmark:

```
$ out/ReleaseX64/dart-sdk/bin/dart pkg/analysis_server/tool/benchmark_tools/big_chain_benchmark/lsp_typing_temporarily_missing_end_brace_in_string_interpolation.dart --types=ImportCycleExportChain --sizes=1024
[...]
====================
size 1024 / CodeType.ImportCycleExportChain:
Initial analysis: 16.173549
Completion after change: 7.824299
Fully done after change: 24.515470
peak virtual memory size: 3941 MB
total program size (virtual): 3941 MB
peak resident set size ("high water mark"): 2125 MB
size of memory portions (rss): 2125 MB
====================
==================================
size 1024 / CodeType.ImportCycleExportChain:
Initial analysis: 16.173549
Completion after change: 7.824299
Fully done after change: 24.515470
peak virtual memory size: 3941 MB
total program size (virtual): 3941 MB
peak resident set size ("high water mark"): 2125 MB
size of memory portions (rss): 2125 MB
==================================
```

Change-Id: I6596252d07a21a487337c39de0cca83e8ec87322
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/453340
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
 2025-10-05 23:40:45 -07:00
Sam Rawlins 33f664940a Bump DAS to use Dart SDK 3.9.0 
Change-Id: I04bc285d822a657adb5573c6de3eb38655ab0fcd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/448232
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
 2025-09-03 12:56:29 -07:00
FMorschel c14b6eb81c [DAS] Adds lints for boolean literals to analysis server packages and fixes occurences 
Bug: https://github.com/dart-lang/sdk/issues/59789
Change-Id: I3287ab55a1b3048c5cbf7f820563fbbd5a292512
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445920
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Felipe Morschel <git@fmorschel.dev>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
 2025-08-28 10:29:10 -07:00
Danny Tuppeny f4e7c3ca7b [analysis_server] Clean up some temp files after test runs 
+ tweak the names of all temp folders created by tests to be more consistent, and more specific so it's easier to tell which are not being cleaned up.

Change-Id: Iabc58576ed7070ebca00a22c7ebb5909b98aa500
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/433821
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
 2025-07-03 09:01:37 -07:00
Jens Johansen 90fb141aa2 [analyzer] Speedup assist calls when file has non-Windows line-endings 
Before an assist call on a file with non-windows lineendings would first
search through the entire file for Windows line endings, then search for
the non-Windows line endings. As such Windows line endings was faster.

This CL changes the semantics slightly from "Windows line endings if
any Windows line endings exist" to "whatever line endings are first
used" which should be good.

It speeds up assist calls with non-Windows line endings:

Statistics on 5 runs each:

```
Windows / 2000: No change.
Windows / 4000: No change.
Windows / 8000: No change.

Unix / 2000: 1000 assist calls: -46.9900% +/- 6.1715% (-0.88 +/- 0.12) (1.86 -> 0.99)
Unix / 4000: 1000 assist calls: -59.1561% +/- 6.3982% (-1.79 +/- 0.19) (3.03 -> 1.24)
Unix / 8000: 1000 assist calls: -63.8429% +/- 4.3083% (-3.68 +/- 0.25)(5.76 -> 2.08)
```

Change-Id: I61278ed4ad31b891e87951da0a6162fe37376888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/437224
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-06-26 23:26:20 -07:00
Jens Johansen 863bc97881 [analyzer] Speedup receiving of data in benchmark 
Change-Id: I3e37a1d8b17393ce3c41e33b1b90049c754cc595
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436921
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-06-26 01:07:09 -07:00
Jens Johansen b79056a0bb [analyzer] Don't calculate add-late assists for other files 
The "add late" assist was broadened in
https://dart-review.googlesource.com/c/sdk/+/176900 with a link to
https://github.com/dart-lang/sdk/issues/44440 where the example is
adding `late` to a field in the same class the user is currently editing
the constructor for.

That makes sense.

The code could also add the `late` keyword to other files which is - I
think - bad for at least two reasons:

  1) It's confusing being given the option to "add late" to something,
     then when trying it nothing seemingly happen, except something does
     happen: another - possibly not open - file has changed.
  2) It requests the resolved unit for another - possibly not open -
     file, which is slow. This means that, at least in VSCode, just
     moving the cursor over something can send requests that takes a
     long time. In practise I've experienced up to ~1.5 seconds, and in
     benchmarks I can make this arbitrarily large by increasing the
     size of the file. Shown below, having 16,000 small classes takes
     around 4 seconds (vs less than 10 ms with this CL).

This CL restricts this to the same file, adds a few tests and updates
a few existing tests.

Note that the existing tests that verified the behavior of adding `late`
to other files was added in
https://dart-review.googlesource.com/c/sdk/+/180087 with a link to
https://github.com/dart-lang/sdk/issues/44534
where the issue discusses a bug where it is applied in the wrong file
and says that it should either be applied to the right file or be
disallowed. The option of allowing it was picked in that instance,
but now at least there's data to show that it comes at a cost.

For an ad-hoc test where I programmatically asks for assists at every
position in `pkg/front_end/lib/src/kernel/body_builder.dart` I go from
1875 positions that takes >= 100 ms to answer to 0 such positions.

For the added benchmark I get this data:

Before this CL:

```
size 1000:
Initial analysis: 0.188291
Action call on 4:11 : 0.308514
Action call on 4:12 : 0.319540
Action call on 4:13 : 0.274678
peak virtual memory size: 2363 MB
total program size (virtual): 2292 MB
peak resident set size ("high water mark"): 258 MB
size of memory portions (rss): 244 MB

size 2000:
Initial analysis: 0.387643
Action call on 4:11 : 0.649877
Action call on 4:12 : 0.550778
Action call on 4:13 : 0.474030
peak virtual memory size: 2325 MB
total program size (virtual): 2325 MB
peak resident set size ("high water mark"): 279 MB
size of memory portions (rss): 277 MB

size 4000:
Initial analysis: 0.753913
Action call on 4:11 : 1.086648
Action call on 4:12 : 1.015921
Action call on 4:13 : 0.915511
peak virtual memory size: 2335 MB
total program size (virtual): 2304 MB
peak resident set size ("high water mark"): 363 MB
size of memory portions (rss): 334 MB

size 8000:
Initial analysis: 1.235531
Action call on 4:11 : 1.880335
Action call on 4:12 : 1.824658
Action call on 4:13 : 1.771081
peak virtual memory size: 2414 MB
total program size (virtual): 2386 MB
peak resident set size ("high water mark"): 436 MB
size of memory portions (rss): 411 MB

size 16000:
Initial analysis: 2.618666
Action call on 4:11 : 3.991542
Action call on 4:12 : 3.775863
Action call on 4:13 : 4.094692
peak virtual memory size: 2576 MB
total program size (virtual): 2516 MB
peak resident set size ("high water mark"): 667 MB
size of memory portions (rss): 611 MB
```

With this CL:

```
size 1000:
Initial analysis: 0.202665
Action call on 4:11 : 0.005730
Action call on 4:12 : 0.003086
Action call on 4:13 : 0.002743
peak virtual memory size: 2174 MB
total program size (virtual): 2170 MB
peak resident set size ("high water mark"): 256 MB
size of memory portions (rss): 247 MB

size 2000:
Initial analysis: 0.433420
Action call on 4:11 : 0.005353
Action call on 4:12 : 0.002116
Action call on 4:13 : 0.002156
peak virtual memory size: 2226 MB
total program size (virtual): 2226 MB
peak resident set size ("high water mark"): 290 MB
size of memory portions (rss): 240 MB

size 4000:
Initial analysis: 0.674376
Action call on 4:11 : 0.004219
Action call on 4:12 : 0.002138
Action call on 4:13 : 0.001625
peak virtual memory size: 2392 MB
total program size (virtual): 2328 MB
peak resident set size ("high water mark"): 306 MB
size of memory portions (rss): 286 MB

size 8000:
Initial analysis: 1.244688
Action call on 4:11 : 0.005225
Action call on 4:12 : 0.002104
Action call on 4:13 : 0.002729
peak virtual memory size: 2349 MB
total program size (virtual): 2338 MB
peak resident set size ("high water mark"): 385 MB
size of memory portions (rss): 366 MB

size 16000:
Initial analysis: 2.776680
Action call on 4:11 : 0.008848
Action call on 4:12 : 0.002854
Action call on 4:13 : 0.002327
peak virtual memory size: 2423 MB
total program size (virtual): 2405 MB
peak resident set size ("high water mark"): 505 MB
size of memory portions (rss): 489 MB
```

It's interesting how the action calls for sizes >= 4000 was slower than
the initial analysis, but I haven't looked into it.

Change-Id: Icefe02073cdf1ad442a37de2030fd7e53f5013b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/436280
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-06-24 00:43:29 -07:00
Jens Johansen 47bc250896 [analyzer] Add benchmark that calls getFixes on an actual error 
This CL adds a benchmark for getFixes calls on an actual error case.
The time it takes is nowhere near the times we're seeing in
http://b/407797012 but it's better than nothing.

The benchmark does 5 requests for `getFixes`.
The first one is always much slower because it has to "discover files".

Comparing old dart releases and CLs
https://dart-review.googlesource.com/c/sdk/+/420323 and
https://dart-review.googlesource.com/c/sdk/+/421220:

3.7.2 was quite a bit slower than 3.6.2.
Both CL 420323 and CL 421220 improve things - both separately and combined.
With both we're faster than 3.6.2 for all but the first getFixes call
(which has to "discover files").

Details:

```
Comparing 3.5.4 with 3.6.2
no change.

Comparing 3.6.2 with 3.7.2
Fixes (1): 16.4789% +/- 8.3240% (0.23 +/- 0.12) (1.39 -> 1.62)
Fixes (2): 300.2940% +/- 21.5781% (0.06 +/- 0.00) (0.02 -> 0.08)
Fixes (3): 220.0321% +/- 23.8171% (0.05 +/- 0.01) (0.02 -> 0.07)
Fixes (4): 89.0472% +/- 86.0948% (0.03 +/- 0.03) (0.04 -> 0.07)
Fixes (5): 202.9467% +/- 22.5906% (0.04 +/- 0.00) (0.02 -> 0.07)

Comparing 3.7.2 with HEAD-ish without the two CLs
Fixes (1): 9.2103% +/- 6.7559% (0.15 +/- 0.11) (1.62 -> 1.77)
Fixes (2): -32.2017% +/- 7.2433% (-0.03 +/- 0.01) (0.08 -> 0.06)
Fixes (3): -39.1903% +/- 7.4656% (-0.03 +/- 0.01) (0.07 -> 0.04)
Fixes (4): -41.5019% +/- 8.2911% (-0.03 +/- 0.01) (0.07 -> 0.04)
Fixes (5): -38.7623% +/- 4.4327% (-0.03 +/- 0.00) (0.07 -> 0.04)

Comparing HEAD-ish without the two CLs with CL 420323 (cache) only
Fixes (1): -5.9976% +/- 4.4944% (-0.11 +/- 0.08) (1.77 -> 1.66)
Fixes (4): -39.3839% +/- 13.3201% (-0.02 +/- 0.01) (0.04 -> 0.02)
Fixes (5): -49.0495% +/- 4.2557% (-0.02 +/- 0.00) (0.04 -> 0.02)

Comparing CL 420323 (cache) only with CL 421220 (element2) only
Fixes (2): -63.4332% +/- 42.9828% (-0.02 +/- 0.02) (0.04 -> 0.01)
Fixes (3): -79.6318% +/- 17.5009% (-0.04 +/- 0.01) (0.05 -> 0.01)
Fixes (4): -68.4995% +/- 11.7414% (-0.02 +/- 0.00) (0.02 -> 0.01)
Fixes (5): -54.6697% +/- 11.1116% (-0.01 +/- 0.00) (0.02 -> 0.01)

Comparing CL 421220 (element2) only with both
Fixes (2): -21.3437% +/- 7.8302% (-0.00 +/- 0.00) (0.01 -> 0.01)
Fixes (3): -17.7975% +/- 10.4789% (-0.00 +/- 0.00) (0.01 -> 0.01)
Fixes (5): -30.5353% +/- 20.5827% (-0.00 +/- 0.00) (0.01 -> 0.01)
```

Change-Id: I477c7a73c669099e2d7bc9d64000cfb78ced2ea4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/421601
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-06-03 07:24:41 -07:00
Jens Johansen a2cb747999 [analyzer] Allow server benchmark to launch via aot + perf 
By changing a benchmark to say

```
LaunchFrom get launchFrom => LaunchFrom.AotWithPerf;
```

and compiling the server with aot:

```
out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot pkg/analysis_server/bin/server.dart
```

running the benchmark will run from the aot snapshot and automatically
launch `perf`, allowing one to do `perf report` after to get a profile
of the entire benchmark.

Change-Id: Idd5c576129acaf4756befb22f9832b24f93b1583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/426480
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-05-06 00:38:16 -07:00
Jens Johansen 6273587103 [analyzer] Add benchmark for many 'prefer_single_quotes' violations 
For the select all one I get
50: 0.310976 seconds
100: 1.054733 seconds
200: 5.535353 seconds
400: 36.099675 seconds
800: 247.919461 seconds

Disabling that (so I can go higher) for the
"Subsequent action call 1" (simulating moving the cursor down a line
in the IDE in the file) I get
100: 0.047451 seconds
200: 0.079821 seconds
400: 0.160073 seconds
800: 0.451288 seconds
1600: 1.311321 seconds
3200: 5.549266 seconds
6400: 32.955526 seconds

Note that for all of this it's just a single file with <size> lines
looking like

```
"num": "num",
```

so even though 6400 is a "large number" it's not entirely unrealistic.

Change-Id: I5c2a51822c0748b4a71d98cef9caeb3e30aec5bc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425503
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
 2025-05-01 00:49:39 -07:00
Jens Johansen 7d82418140 [analyzer] Refactor benchmarks to make it easier to add new benchmarks based on different sources 
Change-Id: I7e6f70c62faad55619de6677100608f406091a5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425502
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
 2025-04-30 23:27:59 -07:00
Jens Johansen f38d092f3a [analyzer] Benchmark can output json with --json 
E.g.

```
out/ReleaseX64/dart-sdk/bin/dart \
  pkg/analysis_server/tool/benchmark_tools/big_chain_benchmark/lsp_with_plugin_that_times_out.dart \
  --types=ImportChain \
  --json \
  --files=10,20,30
```

This is preparation for a future CL.

Change-Id: Icba35f3ab2fad6b645109800376c1eb454af07db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425501
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-04-30 22:29:18 -07:00
Jens Johansen f6fcd37cb8 [analyzer] Add benchmark with plugin that times out 
TL;DR: Add benchmark that shows the Dart 3.7
(https://dart-review.googlesource.com/c/sdk/+/386581 specifically)
introduced a regression.

Details: We've observed that sometimes the plugin that users has
installed times out (takes > 500 ms to answer).

This benchmark simulates that and shows the worse handling of this
introduced in Dart 3.7.

Running 10 iterations each of lsp_with_plugin_that_times_out.dart with
params 10, ImportChain:

Comparing 3.5.4 with 3.6.2

```
Initial analysis: -7.1855% +/- 2.9168% (-0.09 +/- 0.04)
peak virtual memory size: 11.8795% +/- 1.6185% (313.00 +/- 42.64)
total program size (virtual): 12.4293% +/- 1.2818% (323.10 +/- 33.32)
peak resident set size ("high water mark"): -7.4081% +/- 0.9050% (-38.90 +/- 4.75)
size of memory portions (rss): -6.3154% +/- 1.3641% (-32.00 +/- 6.91)
```

I'll note that this is only 10 files and we probably shouldn't put too
much weight on the initial analysis time here. Equivalently memory
probably isn't super interesting.

Comparing 3.6.2 with 3.7.2

```
Initial analysis: -45.8697% +/- 2.7193% (-0.53 +/- 0.03)
Completion call 1: 652.8573% +/- 1.3303% (0.97 +/- 0.00)
codeAction call 1: -0.7637% +/- 0.5174% (-0.01 +/- 0.01)
Completion call 2: 807.2503% +/- 0.7116% (0.89 +/- 0.00)
codeAction call 2: 0.2624% +/- 0.0456% (0.00 +/- 0.00)
Completion call 3: 868.9361% +/- 0.3199% (0.90 +/- 0.00)
codeAction call 3: 0.1433% +/- 0.0287% (0.00 +/- 0.00)
peak virtual memory size: -7.1307% +/- 3.4799% (-210.20 +/- 102.58)
total program size (virtual): -8.1674% +/- 3.5673% (-238.70 +/- 104.26)
peak resident set size ("high water mark"): -1.2546% +/- 0.7151% (-6.10 +/- 3.48)
size of memory portions (rss): -7.6891% +/- 0.9209% (-36.50 +/- 4.37)
```

Again I'll note that this is only 10 files and we probably shouldn't put
too much weight on the initial analysis time here - although we've seen
this improve in other benchmarks too so I do believe we have an
improvement here.
And again memory probably isn't super interesting because of the few
files.
The codeAction calls are basically the same which makes sense: In all
cases it's dominated by the plugin that times out.
The codeAction call does two calls to the plugin and it takes around
1000 ms (a timeout of 500 ms on each plugin call).

Here we see the regression in 3.7 clearly though (cut-out from above):

```
Completion call 1: 652.8573% +/- 1.3303% (0.97 +/- 0.00)
Completion call 2: 807.2503% +/- 0.7116% (0.89 +/- 0.00)
Completion call 3: 868.9361% +/- 0.3199% (0.90 +/- 0.00)
```

Because of https://dart-review.googlesource.com/c/sdk/+/386581 we only
do one request at a time. Before we would interleave the requests,
something like this:

```
Request 1: codeAction:
|--|waiting for plugin|--|waiting for plugin|--|

Request 2: completion:
 |..--|
```

(I'm trying to ascii-draw that when the codeAction is just awaiting the
plugin the completion request can be executed)

Now instead we're doing this:

```
Request 1: codeAction:
|--|waiting for plugin|--|waiting for plugin|--|

Request 2: completion:
 |..............................................--|
```

(I'm trying to ascii-draw that when the codeAction has to finish before
the completion request can be executed)

I'll also note that while it's here shown trough a plugin that times out
the same will likely happen in other circumstances as well. E.g. the
completion resolves with a special call `resolveForCompletion` which in
`performWork` gets priority over other things - but when not
interleaving requests that has very little effect.

For good measure, comparing 3.7.2 with HEAD

```
Completion call 1: 0.6851% +/- 0.2074% (0.01 +/- 0.00)
codeAction call 1: 0.6962% +/- 0.1876% (0.01 +/- 0.00)
peak virtual memory size: -11.7293% +/- 4.7947% (-321.10 +/- 131.26)
total program size (virtual): -12.1763% +/- 4.9125% (-326.80 +/- 131.85)
peak resident set size ("high water mark"): -14.7469% +/- 0.6980% (-70.80 +/- 3.35)
size of memory portions (rss): -10.4518% +/- 0.8927% (-45.80 +/- 3.91)
```

Not a whole lot of change for the time-related things on this benchmark.

Running legacy_with_plugin_that_times_out.dart shows the same thing
(here there's only 1 plugin call instead of 2 though; here only looking
at completion calls):

```
Comparing 3.5.4 with 3.6.2
Completion call 1: -6.1695% +/- 3.6147% (-0.03 +/- 0.02)
Completion call 2: -14.4462% +/- 8.8828% (-0.02 +/- 0.01)
Completion call 3: -16.7707% +/- 7.5412% (-0.03 +/- 0.01)

Comparing 3.6.2 with 3.7.2
Completion call 1: 139.2436% +/- 3.8814% (0.70 +/- 0.02)
Completion call 2: 1128.6580% +/- 14.8207% (1.41 +/- 0.02)
Completion call 3: 589.1425% +/- 11.9186% (0.78 +/- 0.02)

Comparing 3.7.2 with HEAD
no change on completion calls.
```

For fun, lets try to comment out `await completer.future;` in
`pkg/analysis_server/lib/src/server/message_scheduler.dart` that was
introduced in https://dart-review.googlesource.com/c/sdk/+/386581
(again only looking at completion calls):

legacy_with_plugin_that_times_out.dart:

```
Comparing 3.7.2 with HEAD (with commented out await)
Completion call 1: -58.5720% +/- 1.9196% (-0.70 +/- 0.02)
Completion call 2: -82.8149% +/- 1.1050% (-1.27 +/- 0.02)
Completion call 3: -85.6439% +/- 1.5128% (-0.79 +/- 0.01)
```

If looking at the values instead of the percent it looks to almost undo
the change from 3.6.2 to 3.7.2, so let's for good measure compare 3.6.2
with that:

```
Comparing 3.6.2 with HEAD (with commented out await)
Completion call 2: 95.7654% +/- 11.4279% (0.12 +/- 0.01)
```

So one of the calls is slower, but just double, not 10x. I haven't
looked into why.

And for lsp_with_plugin_that_times_out.dart:

```
Comparing 3.7.2 with HEAD (with commented out await)
Completion call 1: -92.9578% +/- 0.5505% (-1.04 +/- 0.01)
Completion call 2: -99.6372% +/- 0.0534% (-1.00 +/- 0.00)
Completion call 3: -99.6370% +/- 0.0429% (-1.00 +/- 0.00)
```

The 1000 ms wait time is gone.

And again let's for good measure compare 3.6.2 with that:

```
Comparing 3.6.2 with HEAD (with commented out await)
Completion call 1: -45.4578% +/- 2.4320% (-0.07 +/- 0.00)
Completion call 2: -96.6303% +/- 0.2481% (-0.11 +/- 0.00)
Completion call 3: -96.2054% +/- 0.3875% (-0.10 +/- 0.00)
```

Here all the completion calls are faster. I haven't looked into why.

Change-Id: I7c312f77b51bb4df68eedeb9bc6e27c2b0175cbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418263
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
 2025-03-31 23:29:39 -07:00
Jens Johansen 5c87f3beb5 [analyzer] Add benchmark simulating 'flutter.setSubscriptions' and opening new files 
This benchmark simulates the current bug at
https://github.com/flutter/flutter-intellij/issues/7980

Comparing this benchmark across dart versions also reveals something
interesting, here run on the "ImportChain" type with 100 files:

Comparing 3.5.4 with 3.6.2
```
Initial analysis: -2.5724% +/- 1.5022% (-0.16 +/- 0.10) (6.35 -> 6.19)
Completion after open of new file: -1.4714% +/- 1.0334% (-0.04 +/- 0.03) (2.92 -> 2.87)
peak virtual memory size: 8.6445% +/- 2.4585% (220.40 +/- 62.68) (2549.60 -> 2770.00)
total program size (virtual): 9.0756% +/- 2.4049% (226.20 +/- 59.94) (2492.40 -> 2718.60)
peak resident set size ("high water mark"): -9.7940% +/- 1.6649% (-58.00 +/- 9.86) (592.20 -> 534.20)
size of memory portions (rss): -8.7961% +/- 3.4971% (-47.20 +/- 18.77) (536.60 -> 489.40)
```

Comparing 3.6.2 with 3.7.2
```
Initial analysis: -8.7696% +/- 2.2759% (-0.54 +/- 0.14) (6.19 -> 5.64)
Completion without opening files: 16.5289% +/- 8.3591% (0.07 +/- 0.03) (0.41 -> 0.48)
Completion after open of new file: 45.0913% +/- 2.8023% (1.30 +/- 0.08) (2.87 -> 4.17)
getAssists call: 21.4736% +/- 2.3049% (0.61 +/- 0.07) (2.86 -> 3.48)
peak virtual memory size: -5.9134% +/- 3.8164% (-163.80 +/- 105.72) (2770.00 -> 2606.20)
total program size (virtual): -6.5548% +/- 4.0754% (-178.20 +/- 110.79) (2718.60 -> 2540.40)
peak resident set size ("high water mark"): -16.3984% +/- 0.5460% (-87.60 +/- 2.92) (534.20 -> 446.60)
size of memory portions (rss): -18.0629% +/- 3.2699% (-88.40 +/- 16.00) (489.40 -> 401.00)
```

Where, between 3.6.2 and 3.7.2 these stand out:
```
Completion without opening files: 16.5289% +/- 8.3591% (0.07 +/- 0.03) (0.41 -> 0.48)
Completion after open of new file: 45.0913% +/- 2.8023% (1.30 +/- 0.08) (2.87 -> 4.17)
getAssists call: 21.4736% +/- 2.3049% (0.61 +/- 0.07) (2.86 -> 3.48)
```

these surely weren't great before, but are much worse now.

Change-Id: I6f94f941cda86b1aa9ee7e7a9b1912df85c7acb2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417820
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
 2025-03-25 08:22:00 -07:00
Jens Johansen daf1084834 [analyzer] Add arguments to to benchmarks 
This CL adds the option of sending arguments to the benchmark(s)
 * Specify what dart to use (e.g. `--dart=/path/to/dart-sdk/bin/dart`),
   e.g. if wanting to run benchmarks on an (old) released version.
 * Specify the number of files to operate on (e.g. `--files=100,200`).
 * Specify the code-types to benchmark
   (e.g. `--types=ImportChain,ImportExportChain`)
 * Specify verbosity, e.g. to debug (maybe `--verbosity=4`) or to run
   benchmarks several times only to look at the final result
   (`--verbosity=-1`).

Change-Id: I5c731f3e6480afdff0546a29c599430d2ab6e7be
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417460
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
 2025-03-25 08:20:20 -07:00
Jens Johansen 6fab57edad [analyzer] Add memory to benchmarks (on Linux) 
Get memory info on Linux from the proc filesystem
(`/proc/<pid>/status`).

E.g.

```
Initial analysis: 2.600716
Completion after change: 0.783488
peak virtual memory size: 2288 MB
total program size (virtual): 2235 MB
peak resident set size ("high water mark"): 302 MB
size of memory portions (rss): 257 MB
```

Change-Id: I3c16d00569d6427627a8629c465e85a15f962c32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417162
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-03-24 01:20:29 -07:00
Jens Johansen 5ba5934201 [scanner] Specialized scanner recovery for missing end curly brace 
*TL;DR*

This improves scanner recovery for a missing `}` in certain situations,
reducing the risk of an in-body change causing a (temporary) outline
change (which in turn could result in the analyzer becoming unresponsive
for "no reason").

*Details*

The behavior of IntelliJ is that when typing `{` it only inserts a
matching end brace `}` when hitting enter.

Imagine you are typing an if: `if (1 + 1 == 2) {`, where you don't hit
enter quickly enough and you trigger a re-analysis at this point.

What happens then is that every method below where you are typing looks
to be local function declarations and thus the outline change. When the
outline change the analyzer has to do a lot of work: everything
(transitively) depending on the file has to be recompiled, and every
strongly connected component is compiled "in one go" where the analyzer
can't respond to queries. So if you have one or more large strongly
connected components depending on the file, or the file itself is part
of such a chain, you will (or at least might) experience that the
analyzer is slow to respond, and it will be extra puzzling because
logically you're just doing an in-body change.

For some code the user might not even naturally hit enter, e.g. `var foo
= {"I'm", "a", "set"};`.

The recovery in the scanner has always been that - upon reaching the end
of the file - it sees that we're missing a `}` and it inserts it at the
end. This CL instead tries to figure out a better place to insert it,
and if successful, will rerun the scanner, instructing it to insert it
at the better place and (hopefully) avoiding a subsequent outline
change.

It does this by looking at the indentation - which is new for recovery -
and under the assumption that the indentation was correct before, will
find the position where the start curly brace was inserted. Note that if
it finds a position it will always be between the start curly brace (the
one missing the end curly brace) and the end of file, and inserting the
missing curly end brace there can't really be "more wrong" than
inserting it at the end (if the new place is not correct it's just
"still wrong").

In the benchmark added we see how quickly we can get completion after
having typed `if (1+1==2) {`, then adding `\n ge\n}` and requesting
completion on the `ge` part, i.e. a simulation of typing

```
if (1+1==2) {
  ge
}
```

and asking for completion at the `ge`.

The change in this CL - on cycles of size 1024 - caused the time to
completion response to come in between ~5 times faster (going from ~10.2
to ~2.1 seconds) to ~18 times faster (going from ~10.3 seconds to ~0.56
seconds):

`CodeType.ImportExportCycle` goes from:

```
+------+-----------+------------+
| Size |  Initial  | Completion |
+------+-----------+------------+
|   16 |  2.019581 |    0.97504 |
|   32 |  3.028976 |   1.031008 |
|   64 |  4.422884 |   1.198383 |
|  128 |  7.612125 |   1.597091 |
|  256 | 12.860864 |   2.906553 |
|  512 | 24.391894 |   5.017093 |
| 1024 | 48.390993 |  10.243085 |
+------+-----------+------------+
```

to

```
+------+-----------+------------+
| Size |  Initial  | Completion |
+------+-----------+------------+
|   16 |  2.107213 |   0.661066 |
|   32 |  3.012952 |    0.70554 |
|   64 |  4.682508 |   0.731176 |
|  128 |  7.508434 |   0.745501 |
|  256 | 13.105477 |   0.852413 |
|  512 | 24.520184 |   1.278403 |
| 1024 | 48.804348 |    2.11903 |
+------+-----------+------------+
```

and `CodeType.ImportExportChain` goes from:

```
+------+-----------+------------+
| Size |  Initial  | Completion |
+------+-----------+------------+
|   16 |  2.059196 |   0.892082 |
|   32 |  3.080717 |    0.93232 |
|   64 |  4.647163 |   1.240303 |
|  128 |  7.377035 |   1.674859 |
|  256 | 12.939432 |   2.705483 |
|  512 | 24.529501 |    5.02689 |
| 1024 | 47.713553 |  10.385469 |
+------+-----------+------------+
```

to

```
+------+-----------+------------+
| Size |  Initial  | Completion |
+------+-----------+------------+
|   16 |  2.020809 |   0.709643 |
|   32 |  3.106856 |   0.648818 |
|   64 |  4.503067 |   0.593152 |
|  128 |   7.45692 |   0.622423 |
|  256 | 13.140592 |   0.606948 |
|  512 | 24.933216 |   0.612687 |
| 1024 | 50.167541 |   0.567544 |
+------+-----------+------------+
```

Change-Id: I8dbefe215162d00a209206ae3db83b2b17505853
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415581
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
 2025-03-20 01:58:45 -07:00
Devon Carew 3c973fb292 [lints] address diagnostics related to strict_top_level_inference 
Change-Id: I228058202855900f0adba73c1ab04d35180a6e5d
Tested: this is an analyzer diagnostic only change
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414900
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Devon Carew <devoncarew@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
 2025-03-17 08:27:57 -07:00
Jens Johansen 3873af28e9 [analyzer server] Legacy protocol debounces getFixes and getAsssits requests too; benchmark 
In reports of the analyzer being slow we've seen `edit.getFixes` causing
a long queue because they take longer to execute than the wait before
the next one comes in.

While we haven't been able to reproduce that, this CL adds a benchmark
that fires *a lot* of both `edit.getFixes` (seen in reports from users)
and `edit.getAssists` (which seems, locally at least, to happen every
time the cursor moves), and debounces them, changing the benchmark
results from

```
4 files / CodeType.ImportCycle:
Initial analysis: 1.322030
Completion after change: 3.096128

4 files / CodeType.ImportChain:
Initial analysis: 1.361750
Completion after change: 3.500849

4 files / CodeType.ImportExportCycle:
Initial analysis: 1.349346
Completion after change: 3.065497

4 files / CodeType.ImportExportChain:
Initial analysis: 1.367151
Completion after change: 3.246891

4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.360573
Completion after change: 3.393901
```

to

```
4 files / CodeType.ImportCycle:
Initial analysis: 1.322070
Completion after change: 0.546532

4 files / CodeType.ImportChain:
Initial analysis: 1.410870
Completion after change: 0.649789

4 files / CodeType.ImportExportCycle:
Initial analysis: 1.349923
Completion after change: 0.741040

4 files / CodeType.ImportExportChain:
Initial analysis: 1.360396
Completion after change: 0.638332

4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.354682
Completion after change: 0.658086
```

Change-Id: Icb0423133726e02e08e204b1c59209264889f8a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413682
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
 2025-03-11 00:22:15 -07:00
Jens Johansen c3fa09f5fc [analyzer] E2E benchmark also supports legacy protocol 
Also add benchmark where lots of hover requests are fired,
mimicking IntelliJ behavior when holding ctrl and moving the mouse over
imports.

I'm getting these results on my machine:

```
4 files / CodeType.ImportCycle:
Initial analysis: 1.249438
Completion after change: 10.143719

4 files / CodeType.ImportChain:
Initial analysis: 1.367604
Completion after change: 9.936909

4 files / CodeType.ImportExportCycle:
Initial analysis: 1.233644
Completion after change: 10.011695

4 files / CodeType.ImportExportChain:
Initial analysis: 1.226382
Completion after change: 9.875991

4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.262932
Completion after change: 9.995607
```

notice the low number of files (in the chain*) or if it even is a chain
etc doesn't appear to change anything for the time it takes to become
responsive again.

Notice that in
https://github.com/dart-lang/sdk/issues/55281#issuecomment-2700500279 I
noticed that something similar happened for `edit.getFixes`, but I'm yet
to actually reproduce that.

Change-Id: Iff04124825c6ea2f759b4d048a0f2988709eaebf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413981
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
 2025-03-10 04:58:39 -07:00
Paul Berry 49ad066aeb Ignore TODOs in newly added analysis_server benchmark 
Since the benchmark has its own `analysis_options.yaml` file, the
files inside it are analyzed with default analysis options, meaning
that `TODO` comments inside the benchmark are now showing up in the
IDE, which is distracting when making edits to the analysis server.

Change-Id: I42b02da06d6754a26157bcf0c07b8d5c4b2ac31d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414240
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
 2025-03-07 07:32:20 -08:00
Jens Johansen a98011a5ef [analyzer] Initial LSP server e2e benchmark 
A benchmark that launches the dart analyzer server in language server
protocol mode and communicates with is as an IDE.
In this case the benchmark generates between 16 and 1024 copies of the
abstract scanner (to get a large amount of code) as well as imports and
exports all the files in cycles and/or chains; performs an edit,
requests completion and times initial startup (with no cache),
completion after change and when it's done analyzing after the change.

It does this in several modes than change the way the files are imported
and exported:
* ImportCycle where file1 imports file2 etc and the last file imports
  file1. There are no exports.
* ImportChain where file1 imports file2 etc and the last file doesn't
  import anything. There are no exports.
* ImportExportCycle where file1 imports and exports file2 etc and the
  last file imports and exports file1.
* ImportExportChain where file1 imports and exports file2 etc and the
  last file doesn't import or export anything.
* ImportCycleExportChain where file1 imports and exports file2 etc and
  the last file imports file1 but doesn't export anything.

For ImportCycle, ImportChain and ImportExportChain things appear to
scale ~linear and - using AOT - have timeings in this ballpark (this is
specifically for ImportCycle):

+------+-----------+------------+------------+
| Size |  Initial  | Completion | Fully done |
+------+-----------+------------+------------+
|   16 |   0.46561 |   0.158765 |    0.40474 |
|   32 |  0.901167 |   0.268819 |   0.859874 |
|   64 |  1.657207 |   0.428747 |   1.488365 |
|  128 |  3.178606 |   0.843576 |   3.040237 |
|  256 |  6.015557 |   1.737661 |   6.010487 |
|  512 |  12.08567 |   2.979242 |  11.736878 |
| 1024 | 24.273368 |   6.101671 |  24.018495 |
+------+-----------+------------+------------+

For ImportExportCycle and ImportCycleExportChain it scales worse and
e.g. ImportExportCycle looks like this:

+------+-----------+------------+------------+
| Size |  Initial  | Completion | Fully done |
+------+-----------+------------+------------+
|   16 |   0.46673 |   0.169486 |   0.406448 |
|   32 |  0.875871 |   0.242876 |    0.85543 |
|   64 |  1.583077 |   0.465915 |   1.506953 |
|  128 |  3.198071 |   0.903894 |    3.09165 |
|  256 |  6.786677 |   2.149489 |   6.779569 |
|  512 | 17.346131 |    8.92149 |  17.971033 |
| 1024 | 63.358453 |  46.152089 |  65.401559 |
+------+-----------+------------+------------+

(In the tables 'Completion' is time until completion answers after a
top-level change and 'Fully done' is time until the analyzer stops
analyzing after a top-level change).

Change-Id: Id7214c0d6c14199f39c0c8a6a8b4941a0e575dc3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413401
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
 2025-03-06 23:43:58 -08:00