This is mainly to exercise the performance test framework, for writing
a report for the test runs.
- adds a flag to specify a file
- logs context information and info from the message scheduler
Started with just these two as an example as I was not sure what performance data we do want to record.
Change-Id: I3e5ff4b77c62d36e47ba7bac8f656b19ba19c457
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Adds a new logging sink that supports an in-memory storage of events for
a subset of the whole server session. This is support for being able to
add 'start' and 'stop' buttons to the insight pages, which will allow
us and users to capture a smaller number of log entries.
Change-Id: Ia562e4da7b09c11ad9191c24cb85102970e1b116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461901
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
In the process of adding this support I decided to add a 'kind' field to
the entries so that it was easier to check to see what kind of entry the
player was suppose to deal with.
I also create constants for the keys used in entries to make it easier
to keep the logger and player consistent.
Change-Id: Ib1f57c8f9d28bcfad6cf9bb3c8c6ec74fcb17c8e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/461520
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The session logger is the first half of the replay mechanism. It
captures data in a log about all of the messages sent to and from the
analysis server. The log player will then take such a log and replay
the portions required in order to drive an analysis server.
This first CL captures all of the communications except those with the
plugin isolates. Adding support for the plugin isolates will require
some additional refactoring that I thought would be easier to review if
placed in a separate CL.
Change-Id: I8f19abd3ebff83ac26584a9377922520857801d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/459341
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This test was added before the unified analytics package and was
intended to guard against gathering analytics where we were not allowed
to do so. We can now gather analytics from other clients as long as we
have displayed the appropriate message, and that should be a sufficient
check at this point.
Change-Id: I1ec68439cb1048d99fbbdec2084332e8e830235a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417861
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
This CL makes three changes:
- moves the message scheduler into a new directory,
- splits the implementation into two files,
- and renames `MessageObject` to `ScheduledMessage`.
It does not make any semantic changes to the code.
The expectation is that we will need to make the message scheduler more
complex as part of improving the performance of the server, and that it
will be easier to do this if the code is structured differently.
Change-Id: I3f8741cadceb34c69fd45c1bf21f331d15824565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/420500
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The PluginServer class needs access to AssistProcessor in order to
compute assists. That class needs access to a few other classes, which
then must also be moved:
* assist_core.dart - the Assist class
* assist_dart.dart - the DartAssistContext class
* assist_generators.dart - the registeredAssistGenerators variable
* assist_performance.dart - the AssistPerformance and
GetAssistsPerformance classes
* assist_processor.dart - the AssistProcessor class with it's
singular API, `compute()`
* performance.dart - the ProducerRequestPerformance class
* the `addCaretAtOffset` helper function, refactored into a
`withCaretAt` extension method
This change is functionally a no-op.
Change-Id: Ic883d21e9cc8c3db1f6093f830f01ec6eb9a0976
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/416680
Commit-Queue: Samuel Rawlins <srawlins@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>
TL;DR: By only responding (for real) to the newest hover request a
benchmark that used to take ~10 seconds now takes ~0.6 seconds.
Details:
In https://github.com/dart-lang/sdk/issues/55281#issuecomment-2700500279
I noticed that some of the performance issues people are seeing fom the
analyzer server stem from many requests being fired, each taking longer
the wait before the next is issued, naturally building up a longer and
loger queue before responses are made. Their it was for `edit.getFixes`,
but I'm yet to actually reproduce that. I did reproduce for hover
requests though, so here I'm debounsing those hover requests.
I'm hooking into the system that already debounces completion requests
and following the pattern used there.
On my machine, running
```
out/ReleaseX64/dart-sdk/bin/dart \
pkg/analysis_server/tool/benchmark_tools/big_chain_benchmark/legacy_many_hover_requests.dart
```
I get these numbers:
Before CL (taken from the parent CL that introduces the benchmark):
```
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
```
With CL:
```
4 files / CodeType.ImportCycle:
Initial analysis: 1.322501
Completion after change: 0.569768
4 files / CodeType.ImportChain:
Initial analysis: 1.347588
Completion after change: 0.635748
4 files / CodeType.ImportExportCycle:
Initial analysis: 1.492362
Completion after change: 0.575233
4 files / CodeType.ImportExportChain:
Initial analysis: 1.331619
Completion after change: 0.576199
4 files / CodeType.ImportCycleExportChain:
Initial analysis: 1.342130
Completion after change: 0.608064
```
Change-Id: Ide3dbc4dfb885af9e1c46a763338ba545c0ab7db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/413982
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds a new page to the analysis server diagnostics that allow you to start/stop streaming the analyzer `PerformanceLog` to the client. This can be useful to capture a slice of this traffic (for example while typing in a file where performance feels bad) without having to enable the on-disk log which can grow very large and hard to match up with specific points in time.
Change-Id: I6bf2b891481191929593beaef813c02df5d3a0c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403420
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
The `AnalysisDriverScheduler` already keeps timings of all of its operations (in `accumulatedPerformance`), but they're not easily accessible to users and might help track down some kinds of performance issues.
This adds a new page to the diagnostics server that shows the timings, as well as a reset button to clear them so they can collect numbers just for a specific operation(s).
It involves some tweaks to the server to handle `POST` (because we shouldn't really use `GET` to mutate anything).
Change-Id: Ia49d471aaa1637a0c978f75569556b26982367d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388561
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Most DTD tests are currently skipped because we're not currently exposing the LSP handlers, however I temporarily added them and verified with this change that those tests pass (both success and error requests).
Change-Id: I001b7b07c99be18a3711a434bdd081a631e4b4c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383842
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
If analysis failed due to an exception, "dart analyze" may still report "no issues found" because it didn't get any server errors.
It didn't get server errors for a number of reasons:
1. Analysis errors were silent (see https://github.com/dart-lang/sdk/issues/39284)
2. `server` in ErrorNotifier was always `null` because the code that set it did so too early
3. `ErrorNotifier` was never added to the instrumentation service, so never got called anyway
Additionally, "dart analyze" printed "No errors found!" even if server errors occurred (as long as the server didn't crash).
This change fixes up the server reference in ErrorNotifier, adds it to the instrumentation service and uses a new flag ("--disable-silent-analysis-exceptions") to allow opting-in to getting analysis errors to the client. It also updates "dart analyze" to not print "No errors found!" (and to not use a 0 exit code) when server errors occur.
Because this change "fixes" ErrorNotifier, it's possible that with this change clients will now get additional error notifications (non-silent exceptions that were being dropped previously) which could result in users seeing more errors - but presumably errors that should have been reported before anyway.
Fixes https://github.com/dart-lang/sdk/issues/49931
Change-Id: I4948117c78b8f382550b7641076de443250bba6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358902
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In order for CorrectionProducers to be used in analyzer plugins, we
need to access DartFixContributor which needs to compute fixes via
FixProcessor. So both DartFixContributor and FixProcessor need to be
moved into analyzer_plugin (eventually). For now, to support
prototyping, I am moving FixProcessor to its own library, and
separating all of the built in mappings (from diagnostic to producer
generators).
I think this separation actually stands on its own as being tidier,
simplifying fix_internal.dart, and separating code from data, as it
were.
Work towards https://github.com/dart-lang/sdk/issues/53402
Cq-Include-Trybots: luci.dart.try:flutter-analyze-try,analyzer-win-release-try
Change-Id: I3b4fadc7ed94c23597d72bef7dcd832380d34e9a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345561
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Keerti Parthasarathy