Analyzer response to LSP requests extremely slow w/ high latency reported #56307
Comments
|
Summary: The Dart analyzer in VS Code is experiencing intermittent slowness, causing delays in autocomplete, error reporting, and editor responsiveness. The issue occurs multiple times per hour and lasts for 30 seconds to 3 minutes. The user suspects the project size or configuration might be contributing to the problem. |
dart-github-bot
added
area-analyzer
|
@DanTup In case you can help in terms of getting enough information to be able to determine the reason for the long analysis times. |
Latency here is the time difference between use constructing a request to the analysis server (done in the VS Code extension) and the server starting to process it. It generally means the analysis server was busy (it's single threaded) although there is the possibility that the delay could be in the VS Code side (especially if it itself is hanging!) or affected by other VS Code extensions (since all extensions run single-threaded in a single Node process). Temporarily enabling the analysis server instrumentation log might give some insight into what the server is doing during this period. The file can get very large and will contain contents of your files, so sharing these logs may be difficult, but if you can get a copy of one after this happens, we may be able to provide some idea of what to look for in it (in particular I wonder if something like a context rebuild is happening - something that can occur if a
Is it only the editor that freezes when this happens, or the system in general? Have you ever been able to view Task Manager (or run The output of |
srawlins
added
the
needs-info
Thank you for the info. I also use VSCode for dotnet and Angular development and haven't encountered the issue there, but it's possible that it's a dart specific plugin. Think all I've got installed is the official Dart plugin and the Dart Data Class Generator.
I'll do that today and update this issue with some logs.
The editor freezing is relatively uncommon, seems like it only happens when I save a file, status bar say something along the lines of "saving and applying code actions". I've never had the system itself freeze, and whenever I've looked at the task manager during one of these episodes, I haven't noticed anything strange. Some high-ish CPU usage, but not like it's pegged at 100% or anything.
Here's that output, not hanging currently but I'll grab it again as soon as it is: |
|
I also should have mentioned that my teammates have also complained about hangs/slowness in the same project, which is what makes me suspicious that there might be something about the project itself that is causing some issues. In my initial efforts to debug, I went through |
|
Some additional info: I dug into the Analysis Server Diagnostics and saw that there are a handful of exceptions. The exceptions throw out an enormous wall of text that starts with: I verified that the indicated library exists at Stack trace from the diagnostics page looks like this: There were 10 similar errors listed, it seems possible that they're connected to the hangs. |
|
This is the same exception again, I still suspect that this is because we try to do more than one operation concurrently in DAS: analysis and handling requests. The solution is probably using a single scheduler. |
github-actions
bot
removed
the
needs-info
lrhn
removed
the
triage-automation
|
I've captured some analysis-server.log output during a time period that I was experiencing a lot of hangs. The worst hangs were happening on save, with the status bar showing "applying quick-fixes," but I did have a period after a save hang was complete where the autocomplete suggestion box was just showing "loading" and inline diagnostics weren't updating. The excerpt that I extracted only covers ~3 minutes but it's about 5600 lines long. The project that I'm working in does have 442 warnings and >2k infos, could that be why the analyzer is getting stuck? |
|
Thanks for the log! Running "Fix All" (particularly with a large number of diagnostics) can be an expensive operation (because we compute fixes, apply them to temporary overlays, re-analyze all affected files, and then check if there are more fixes and repeat). From the log it seems you're running this on-save and saved multiple files, which means this operation is occurring multiple times. That said, I see a lot of diagnostics being sent while the operation is running, and this is unexpected. While we re-analyze during this operation (to look for another round of fixes), the diagnostics from analyzing should be suppressed (because they're based on temporary overlays that don't match what the client has). I'm not sure it accounts for a lot of the time (versus all of the analysis), but it doesn't seem right so I'll try to reproduce. Something I overlooked in your original screenshot it that the first bar in the graph was blue. Can you confirm that this was a |
Digging more, this is actually from an in-process analysis started before the Fix All command. The log shows:
I actually think the issue here might not be related to Fix All itself, but could be that the analysis took a long time after you modified Is it possible you can try capturing logs and modify the file The difference in the previous log is > 10s and this could be a result of how much code needs to be re-analyzed when you modify that file (files that depend on it). |
bwilkerson
added
the
needs-info
|
I set disabled
Been trying to do this for a couple of days but I don't actually have any changes to make to that file at the moment, and my contrived examples don't seem to be replicating the issue. I am having the issue really badly today in another file. Basically, any time I try to trigger code completions to pop up, the analyzer is hanging for around a minute. If I wait for it to return with analysis and change what I'm typing, it immediately freezes again. I've restarted the language server and captured the log demonstrating this, attaching it below. What I did was:
I do see one pair of Any ideas? |
|
We've got a directory structure that I suspect might be non-standard, looks something like this It's set up with a 2nd project root inside of our app's project root, and then has this as a dependency in the dependencies:
ApplicationServer:
path: ./api-clientIt definitely seems like the hangs are happening much more frequently when trying to get diagnostics from models inside of the |
github-actions
bot
removed
the
needs-info
|
@josephemorgan I wouldn't expect nested projects or path dependencies to cause any additional problems. Changing code in one project may result in code in the other project being re-analyzed, but I don't think this would be different to if they were in the same project (@scheglov may be able to confirm). Are you able to capture an instrumentation log (see #56307 (comment)) for this issue? That log is captured by the server rather than the client, and includes additional logging (such as file watcher events and analysis context rebuilds). There's some analysis in your log that it's not obvious what the trigger is, so I wonder if this log gives the whole picture. Like the logs above, the log file can get quite large and it will contain parts from your source files (such as in |
pq
added
type-performance
Yes, when DAS sees a file change, it notifies all |
|
Sorry, know it's been two weeks here, haven't forgotten about this, just been swamped, will try to update with the instrumentation log tomorrow. |
|
Here's that instrumentation log: At this point, I'm pretty confident that the issue ONLY happens when the analysis is operating on files that our in our api library (which is a subfolder in the general project). LSP responses are totally normal if they're triggered on code from a Flutter library or anything from the When the analyzer is triggered against anything from Those files are exported through a file called library OurAppServer.api;
import 'package:OurAppServer/model_base.dart';
import 'dart:async';
import 'dart:convert';
import 'dart:io';
import 'package:http/http.dart';
import 'package:flutter/foundation.dart';
import 'package:intl/intl.dart';
import 'package:meta/meta.dart';
part 'api/some_autogenerated_client.dart' // Few dozen of these, for each controller in our asp.net backend
part 'model/some_autogenerated_model.dart' // close to a thousand of theseAnd then, of course each of those I have no idea if any of this is useful but I can't shake the suspicion that something about the api library configuration is causing issues. |
That's quite likely the source of the problem. When the analyzer needs to resolve a file, it ends up analyzing all of the files in the library cycle [1]. Even if you only have one library in the library cycle (which appears to be the case, as long as You might want to consider breaking this single monolithic library up into multiple smaller libraries, organized in such a way that, as much as possible, they are not all dependent on everything else. The smaller a cycle in the library graph is (in terms of number of files), the faster the analysis of that cycle will be. [1] "cycle" in the sense of a cycle in a graph, where the vertices are the libraries and the edges are defined by the imports between those libraries. |
|
I see, that makes sense to me. The code is all auto-generated using |
|
Where are we currently standing on this issue? @bwilkerson @DanTup |
|
From the last few comments above, it sounds like the poor performance might be caused by the structure of the package, resulting in a lot of analysis happening during typing. I don't know how much can be done about that, although it would be useful to try and get a way to repro this. @josephemorgan I'm not familiar with |
|
Also - on the latest Flutter master there is a new page in the analysis server diagnostics (which you can access by running the Dart: Open Analyzer Diagnostics command in VS Code). It shows some timings from the analysis driver like this:
If we don't have a repro, it may be useful to capture these numbers. You can load the page, press the Reset button at the bottom, and then type a character in the offending file, then refresh the timings and copy/paste the details here. They may give an idea of how long is spent on analysis and the number of files etc. |
|
I've made some progress into identifying exactly what's causing the issue with my project setup.
Imagine: // api.dart
library someNamedLibrary; // Tool produces a named library, not configurable
part "models/modelA.dart";
part "models/modelB.dart";
part "api/clientA.dart";
part "api/clientB.dart";The individual files look something like: // modelA.dart
part of "someNamedLibrary";
class ModelA extends Whatever {
// What you'd expect
}I've been experimenting with some solutions, I tried generating the our api library with the // api.dart
export "models/modelA.dart";
export "api/clientA.dart";I found that the analyzer performance issues totally disappear when the files are split into multiple libraries, and then exported in a barrel file (which aligns with what @bwilkerson indicated was the likely cause of the problem) But of course So to me, it seems like my team's problem is that the dart analyzer has a much harder time analyzing a single large library declared across multiple files using I'm not sure if that's the dart analyzer's fault, I wouldn't necessarily expect it to perform well with that kind of setup. And I don't know how many dart/flutter developers are using Anyway, if it is a goal to have the analyzer perform well on large multipart libraries, I can spend some time trying to contrive a project that reproduces the issue. In the meantime, I have this: the only call where I've tried getting rid of the explicit library name manually, since Effective Dart mentions that make it harder for the analyzer to find files, but that didn't seem to have an effect. Also, weirdly, my only coworker who has access to an arm macbook claims that the analysis server doesn't lag for nearly as long when he's using it. |
johnniwinther
added
area-dart-model
I'm intermittently having extremely slow dart analyzer performance with VS code around 10-15 times an hour.
A typical instance starts with me typing to fix an error or triggering autocomplete. When I do so, I get
Loading...in the autocomplete pop-up, sometimes the VS Code status bar shows "Analyzing" with a spinner. While the analyzer is loading, error indicators in the editor window don't update (they'll report errors at locations that don't have errors) and autocomplete won't show anything. Sometimes, but not always, my editor will freeze completely until the analyzer unfreezes. The hangs usually last anywhere from 30 seconds to 3 minutes.I suspect the issue might have something to do with how large the project is, or maybe there's something strange about our project configuration.
The analysis server diagnostics typically looks like this after freezing:
I understand that "latency" means the server is busy and can't start handling a request, is there any way to determine what it's busy doing?
Please let me know what other information I can provide or what debugging steps I can take.
Dart Info:
Flutter Doctor:
The text was updated successfully, but these errors were encountered: