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>
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>
This was mostly a rename/move of the folder (and the analysis server updated all references), but I also had to:
- add `integration_test/analysis_options.yaml` to import from `../test` to get the same lint ignores
- update paths of exclusions in `verify_sorted_test.dart`
By moving all of the tests that start the server out-of-process out of test, we can:
1. Use "dart test" to just run the faster tests ("dart test test") and get functionality of the pkg:test runner (for example running tests concurrently and JSON output)
2. Allow VS Code to spawn different debug sessions for the "test" and "integration_test" folder, which means we can use a `preLaunchTask` to trigger compilation of the analysis server from source whenever running integration tests (avoiding having to compile manually, or run from source in a way that compiles a new server for each test suite)
Change-Id: I37cc03dc32d08c5b51a2eab79f6338bb079b32ac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/434801
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
For https://github.com/Dart-Code/Dart-Code/issues/4729 we added a configuration setting to let you control how much documentation was included in responses. The motivation here was to reduce the completion payload sizes when running in remote workspaces (Dart-Code would adjust the default setting if not explicitly set by the user based on the workspace kind).
However in hindsight, forcing no docs on Hovers just because we didn't want them in Completion requests was a bad choice, because these are individual requests where the payload size is less important and seeing the docs is useful.
So this alters the setting to accept a `Map` to allow you to have different preferences for each request that returns docs. Dart-Code will be updated to adjust the defaults accordingly (after this lands) so that Hover/SignatureHelp can default to `"full"` even in remote workspaces.
Work towards https://github.com/Dart-Code/Dart-Code/issues/5499
Change-Id: Ib64f762a0559c7afc7653fad9749fc208beee8b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431280
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
There are a few things in this CL that were difficult to separate testing of (because they're all part of the same feature):
1. sets `requiresTrustedCaller=false` on the `executeCommand` handler so that commands can be called over DTD. It adds the same flag to the command handlers themselves, so a command can control whether it can be called over DTD or not (right now we allow everything except `logAction` and `sendWorkspaceEdit` which are both commands used internally and not appropriate for DTD clients to call).
2. Removes the allow-list on DTD methods, allowing all LSP shared methods to be available over DTD
3. Extends the integration test classes to support reverse-requests so we can verify the edits being sent back to the editor when calling the code actions commands over DTD
4. It also fixes a few bugs where we read the callers capabilities instead of the editors capabilities (which until now would always be the same in those places, but with this change are not).
Change-Id: I6d271ddad6dc1b00a98b10b735763a368c91af7a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428784
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This adds an optional version number to AddContentOverlay and UpdateContentOverlay in the legacy protocol.
It also moves some code (such as the `Map` that stores the current document versions) from the LSP server into the base class, and updates the overlay handlers to update it.
And finally, it removes the FailingTest() annotations on the versioned EditArguments test since they now work.
Change-Id: Icf2a2825eb6227f5faa3e21ae6c3a7d15997ef5a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404821
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
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>
I wrote a test that generates 10,000 lines of code, each containing one
violation of `prefer_single_quotes`, computes the fixes for all of the
diagnostics, and applies the 20,000 edits, measuring how long the
application takes.
Before this change the average was 3355.0 ms.
After this change the average is 3.8 ms.
The change was inspired by Jens.
Change-Id: Icd54a81ca3848fd5f0168934f713a7be8caec359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425601
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
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>
The term "CodeAction" is a bit overloaded. It could mean both an
individual result from the `textDocument/codeAction` request (which is a
`Command` or a `CodeAction`), or the `CodeAction` type defined in
the spec (which the spec refers to as a "Code Action literal").
To reduce confusion where we have similar APIs that operate on
"Code Actions" (CodeAction|Command), this renames the `CodeAction` class to
`CodeActionLiteral` and we will use the term `CodeAction` to mean either of
those types.
To make things simpler to review, this change _only_ renames the class, and also swaps the order of the types in some places that used `Either2<Command, CodeAction>` (which is opposite to the spec and some other code). Some further clean up will be done in a separate change.
Change-Id: Idcd8265f9229c3450004e68334e98a7b530330a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425300
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
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>
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>
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>
Recently a bug was fixed in the formatter, regarding how declarations
preceded by an end-of-line comment are formatted. Good to just bundle
the formatting changes into one CL.
Change-Id: Ieab8ec3263932505f8b8da77fbe637dffc61b46d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417040
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This lint rule is a core lint rule; we have suppressed it only for
pre-existing code reasons.
There are a few individual files which simply have a consistent pattern
of including underscores in some names, so I add inline ignores there.
Change-Id: I89e6010203868fc10fda12b15353de41881d9b15
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416900
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
*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>
This is required so that an analyzer plugin can process producer generators that are registered in a plugin isolate.
* Change `AssistProcessor._generators` and
`AssistProcessor._multiGenerators` into private top-level variables
which are only used as "built-in" assist processor generators. They
must be explicitly registered, which we see much of in this change.
* Rename all of the lists of _generators_ and maps with lists of
_generators_, which were named "producers". The new names are
"generators." This leads to giant diffs because of alphabetizing.
Change-Id: Id4432737daaec1bb282f0b387619b23c18c0ea55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/414665
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
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>
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>
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>
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>
Jens Johansen