After upgrading to Dart Code 3.15 and VSCode to 1.50, Dart Code gets stuck on "Analyzing", making every operation, from coded completion to saving files, take too long.
To Reproduce
Expected behavior
After doing initial analysis, code completion should take from a few milliseconds up to a few seconds
Versions (please complete the following information):
Output from flutter doctor -v
❯ flutter doctor -v
[√] Flutter (Channel stable, 1.22.0, on Microsoft Windows [versão 10.0.19041.508], locale pt-BR)
• Flutter version 1.22.0 at D:\dcvia\Desenvolvimento\Android\flutter
• Framework revision d408d302e2 (10 days ago), 2020-09-29 11:49:17 -0700
• Engine revision 5babba6c4d
• Dart version 2.10.0
[√] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
• Android SDK at D:\dcvia\Desenvolvimento\Android\Sdk
• Platform android-29, build-tools 29.0.3
• ANDROID_HOME = D:\dcvia\Desenvolvimento\Android\Sdk
• Java binary at: C:\Users\dcvia\android-studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
• All Android licenses accepted.
[√] Android Studio (version 4.0)
• Android Studio at C:\Users\dcvia\android-studio
• Flutter plugin version 49.0.2
• Dart plugin version 193.7547
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b01)
[√] VS Code (version 1.50.0)
• VS Code at C:\Users\dcvia\AppData\Local\Programs\Microsoft VS Code
• Flutter extension version 3.15.0
[√] Connected device (1 available)
• SM G950F (mobile) • ce11182b72a0ba3a02 • android-arm64 • Android 9 (API 28)
Did you find a solution? I experience the same problem and i have to wait about 5-10 seconds just for an autocompletion.
Could you try enabling the analysis server log and then reproduce the issue, and provide the log? (note: it may include parts of your open files, so best to reproduce with a clean/new project).
Thanks!
Also on a new MacBook Pro, same issue. Dart Code is taking up almost 100% CPU "analyzing" and whole system freezes for few seconds until it finishes. Then after few changes running smoothly, it goes back to "analyzing".
@campovski are you able to capture the log linked above?
@DanTup Yes, I managed, here it is. I hope it will be of some help. Currently Dart-Code drains 1% battery per minute, although I am not completely sure it is only the analysing part that is bugging it. Even when I am not touching the files for few minutes, the CPU spins like crazy.
Same here. Every time I touch the code, it sends RAM usage flying and takes forever to stop analyzing.
Also runs 'pub get' every few minutes for no apparent reason.
I tried 'flutter clean' but that didn't work. My project has many files linked through 'part of' directives, maybe that's why?
This is on VS Code 1.49.3 with only the latest Flutter & Dart plugins enabled.
Previous versions of the plugin worked fine.
@ckt0 Shouldn't be, I only have one BLoC using part and it is still the same. Probably it would be useful to provide all logs @DanTup ?
Another one, failing to respond to ⌘ + .. Also just saving a file sometimes takes ages...
Thanks for the logs - I can definitely see a lot of slowness for some requests, though it's not entirely clear why (the log also doesn't seem to contain any analysis status notifications where I'd expect to see the appear/disappear).
Some things to try:
Enable the dart.previewLsp setting. This moves more of the work into the server and has some reasonable performance gains (especially when it comes to code completion). LSP will become the default in the near future.
If you were running debug sessions when seeing these issues, try this beta build (v3.15.1 may be released later today, so if you've already been upgraded to v3.15.1 by the time you read this, no need to install the beta). There was a severe performance issue in v3.15.0 that would consume vast amounts of CPU when printing large strings (or large numbers of) while your app was running.
Run code --status when the CPU is high / stuck analyzing and provide the output here.
If anyone can reproduce this reliably on a public project they can share, that may help me track down what's going on.
Same here. Every time I touch the code, it sends RAM usage flying and takes forever to stop analyzing.
Also runs 'pub get' every few minutes for no apparent reason.I tried 'flutter clean' but that didn't work. My project has many files linked through 'part of' directives, maybe that's why?
This is on VS Code 1.49.3 with only the latest Flutter & Dart plugins enabled.
Previous versions of the plugin worked fine.
Okay... I no longer have this issue and I think I know why. I had 2 const List<String> arrays of 10,000 words each, in one of my files. That maybe what caused the analyzer to take so long. I made them load in as runtime assets and everything works fine again.
@ckt0 I tried creating such lists but didn't see any issues. If you can reproduce this in a small sample you can share, please let me know. I don't see any reason why 10k items in a const list should cause any performance issues.
Thanks!
@DanTup I was thinking maybe the plugin was looking for references to elements in these lists throughout the project. I remove the lists and everything is back to normal.
The only other changes I made were:
I still feel it was removing the list that made the difference. If I can reproduce the issue I will let you know!
Thanks for the logs - I can definitely see a lot of slowness for some requests, though it's not entirely clear why (the log also doesn't seem to contain any analysis status notifications where I'd expect to see the appear/disappear).
Some things to try:
- Enable the
dart.previewLspsetting. This moves more of the work into the server and has some reasonable performance gains (especially when it comes to code completion). LSP will become the default in the near future.- If you were running debug sessions when seeing these issues, try this beta build (v3.15.1 may be released later today, so if you've already been upgraded to v3.15.1 by the time you read this, no need to install the beta). There was a severe performance issue in v3.15.0 that would consume vast amounts of CPU when printing large strings (or large numbers of) while your app was running.
- Run
code --statuswhen the CPU is high / stuck analyzing and provide the output here.If anyone can reproduce this reliably on a public project they can share, that may help me track down what's going on.
Thank you, enabling dart.previewLsp solved the issue for me (at least for now). One question, when you mention that the work is moved the server, does it mean that a service is created for dealing with the analysis which isn't attached to VS Code process?
Thank you, enabling
dart.previewLspsolved the issue for me (at least for now)
Glad to hear! I'll close this on the basis that the non-LSP version is going away over the coming releases.
does it mean that a service is created for dealing with the analysis which isn't attached to VS Code process?
This has always been the case, though the protocol that the VS Code extension uses to communicate with the Dart language server is changing slightly with this (it used to be a custom protocol designed for Dart, but LSP is a standard that many languages/editors use).
It's fairly common for languages to have their own "language servers" that run separately from the editors. This allows sharing a lot of functionality (like code completion and analysis) between editors much more easily (and LSP aims to make this even easier).
Hope this helps!
I battled with this for a few hours. In case anyone else is battling with this, in the end I tracked the issue down to a half written line of code:
Future<List<>>
@raphael-bmec-co thanks for tracking this down and posting! I was able to reproduce the same and have filed an SDK issue at https://github.com/dart-lang/sdk/issues/44477.
The same issue with Future<List> after I used Quick Fix on Visual Studio Code
@duannl if you're able to reproduce this and share a complete code example that triggers it, please file a new issue. Thanks!
Most helpful comment
I battled with this for a few hours. In case anyone else is battling with this, in the end I tracked the issue down to a half written line of code:
Future<List<>>