9f42ef774e
The legacy_many_files_in_flutter_set_subscriptions benchmark shows how "flutter.setSubscriptions" calls can make the analyzer slower to respond. What happens is this: * The user opens a new file in the IDE. * The IDE sends the `flutter.setSubscriptions` request which equates to a call to `getResolvedUnit` for each file in the request. If this is, say, 300 files it's 300 calls to `getResolvedUnit`. * The IDE sends a `edit.getAssists` request for the newly opened file. This request starts processing, reaches `getResolvedLibrary(file)` which calls `getUnitElement` ultimately adding the path to `_unitElementRequestedFiles` which in `performWork` is done _after_ `_requestedFiles`, meaning it has to do all the flutter requested files first. * The user might then request completion for instance, but because the analyzer only processes one request at a time it has to wait for the `edit.getAssists` request to finish first, which had to wait for the files from the `flutter.setSubscriptions` request to process. All in all it's a lot of waiting for the user. This CL adds a `interactive` option to the `getResolvedUnit` call. It defaults to true in which case files are still added to `_requestedFiles` and processed the same. If it's false it will instead be added to a newly introduced list instead and processed at a lower priority. Subscription requests are changed to pass `false` to `interactive`, avoiding the scenario above. Comparing before this CL with this CL on the "legacy_many_files_in_flutter_set_subscriptions" benchmark with 100 files / CodeType.ImportChain these are the statistics on the changes based on 5 runs each: ``` Completion after open of new file: -81.6652% +/- 7.7564% (-3.70 +/- 0.35) (4.53 -> 0.83) getAssists call: -96.6315% +/- 0.9307% (-3.61 +/- 0.03) (3.74 -> 0.13) peak virtual memory size: -5.6786% +/- 3.2964% (-139.00 +/- 80.69) (2447.80 -> 2308.80) total program size (virtual): -4.6387% +/- 3.8146% (-110.80 +/- 91.11) (2388.60 -> 2277.80) ``` Even when https://github.com/flutter/flutter-intellij/issues/7980 is hopefully fixed I think it is a fair change to de-prioritize a non-interactive request. Change-Id: Icba2faebf12f9913cf24db7cb90fdc6f4c74164e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/418020 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Jens Johansen <jensj@google.com>
analysis_server
A long-running process that provides analysis results to other tools.
The analysis server is designed to provide on-going analysis of one or more code bases as those code bases are changing.
Using the server
The analysis server is not intended to be used stand-alone, and therefore does not have a human-friendly user interface.
Clients (typically tools, such as an editor) are expected to run the analysis
server in a separate process and communicate with it using a JSON protocol. The
original protocol is specified in the file analysis_server/doc/api.html
and Language Server Protocol support is documented in
tool/lsp_spec/README.md.
Features and bugs
Please file feature requests and bugs at the issue tracker.