Dart Analyzer very slow/stuck

[JonasJW]

Dart & Flutter has suddenly become unusable slow in VSCode. Intellisense won't load within 30+ seconds, syntax highlighting won't update, jumping to code definitions loads infinitely, etc.

This seems to be especially the case on bigger projects, on a newly created project it works fine. I tried switching to Android Studio which seems to behave similarly (maybe a little better).

I tried uninstalling all extensions, even completely removing VSCode with any data stored and reinstalling it. As soon as I install the Dart extension, it is unusable. I also tried setting the following settings:

"dart.previewLsp": true,
"dart.useLegacyAnalyzerProtocol": true,
"dart.useLsp": false,
"dart.autoImportCompletions": false,

I'm on macOS 14.4, VSCode Version 1.87.2 (Universal),

In the Activity Monitor, there is the dart:analysis_server.dart.snapshot process running with around 1 GB of used memory. I'm not sure if this is normal.

Here is a screenshot from the Dart Analyzer (which I'm also having trouble opening)

dart info output:

General info

• Dart 3.3.2 (stable) (Tue Mar 19 20:44:48 2024 +0000) on "macos_arm64"
• on macos / Version 14.4 (Build 23E214)

Project info

• sdk constraint: '>=2.17.0 <3.0.0'

Process info

Memory	CPU	Elapsed time	Command line
6 MB	0.0%	11:53	dart devtools --machine --allow-embedding
393 MB	100.6%	11:53	dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.85.20240318
29 MB	0.0%	11:53	flutter_tools.snapshot daemon
35 MB	0.1%	00:23	flutter_tools.snapshot debug_adapter
121 MB	10.8%	00:23	flutter_tools.snapshot run --machine --start-paused -d B95DD896-131D-4163-A83C-1AC8A70E8560 --devtools-server-address http:/ --target /main.dart --web-renderer canvaskit --web-port 5000

Any recommendations on how I could possible fix this would be very welcome!

[keertip]

@DanTup , do you see this? Have there been more reports of this kind?

[keertip]

/ cc @bwilkerson

[DanTup]

I've not seen any other reports like this. 100% CPU certainly does not look healthy if it's persisting for a long period after initial analysis.

@JonasJW a few questions:

• How big is the open workspace (code --status I think should give a summary of the number of each file type)
• Might it contain any symlinks (that could result in analyzing more than just this folder, or even cycles?)
• You noted that this issue started recently - are there any things that you updated around the time it started (VS Code, the VS Code extensions, the Dart/Flutter SDKs)?
• Are you able to get a screenshot of the servers Timing page (the one you gave above was the Completion page) which will include timings for a larger set of requests

[MaximeRougieux]

We were having the same issue and using the custom_lint package (v0.5.7).

Removing it completely seems to have solved the issue for us, are you using it too, and can you try to remove it to confirm it comes from there if you are ?

[keertip]

/cc @scheglov

[JonasJW]

@DanTup Thanks for the response and sorry for the late reply.

code --status output:

``` Version: Code 1.87.2 (863d2581ecda6849923a2118d93a088b0745d9d6, 2024-03-08T15:21:31.043Z) OS Version: Darwin arm64 23.4.0 CPUs: Apple M1 Pro (8 x 24) Memory (System): 16.00GB (0.06GB free) Load (avg): 5, 5, 6 VM: 0% Screen Reader: no Process Argv: --crash-reporter-id 0c0cb32f-913b-418e-b987-7370929419d6 GPU Status: 2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled CPU % Mem MB PID Process 0 115 38907 code main 7 66 38910 gpu-process 0 16 38911 utility-network-service 0 33 38923 shared-process 0 33 82195 ptyHost 0 0 83841 /bin/zsh -il 0 0 90120 bash /usr/local/bin/code --status 9 66 90129 electron-nodejs (cli.js ) 5 246 83837 window [5] (auto_router.gr.dart — exercisable_flutter) 0 98 83839 extensionHost [5] 0 33 83879 electron-nodejs (config.js ) 0 0 83961 /usr/bin/script -t 0 /dev/null /usr/bin/arch -arm64e xcrun xcdevice observe --usb 0 16 83962 /Applications/Xcode.app/Contents/Developer/usr/bin/xcdevice observe --usb 0 0 83963 /usr/bin/script -t 0 /dev/null /usr/bin/arch -arm64e xcrun xcdevice observe --wifi 0 16 83964 /Applications/Xcode.app/Contents/Developer/usr/bin/xcdevice observe --wifi 0 426 83884 /Users/jonas/Documents/flutter/bin/cache/dart-sdk/bin/dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.85.20240327 0 0 83886 /Users/jonas/Documents/flutter/bin/cache/dart-sdk/bin/dart devtools --machine --allow-embedding 0 33 89935 electron-nodejs (config.js ) 0 33 89961 electron-nodejs (config.js ) 170 1081 90000 electron-nodejs (config.js ) 0 33 83840 fileWatcher [5] Workspace Stats: | Window (auto_router.gr.dart — exercisable_flutter) | Folder (exercisable_flutter): more than 20346 files | File types: transitive_digest(3856) json(1582) png(1354) flat(1004) | jar(976) xml(843) webp(646) ttf(344) stamp(334) | len(275) | Conf files: launch.json(1) | Launch Configs: dart(13) ```

To be honest, I'm not quite sure what you mean by your question about symlinks or how I can find out.

Yes, this issue seems to have started just recently without making any noticeable changes such as updating SDKs, installing extensions, etc.

Here are further screenshots, I hope this is the server timing page you meant.

If you have any recommendations what I can try to fix this issue, I'm happy to try that. As mentioned, I have already tried uninstalling Flutter/Dart, VSCode, etc. at the moment I don't know what else I could try.

[lulupointu]

For us updating custom_lint to 0.6.4 fixed the issue 🎉

[DanTup]

@JonasJW thanks - the page I meant was the one marked "Timing" on the left.

Can you also confirm whether you're using any analyzer plugins? A few comments above suggest custom_lint might have have issues (that may be fixed in 0.6.4).

You should be able to check for symlinks by running find . -type l -ls in your project folder.

[JonasJW]

@DanTup thanks for the clarification!

I don't use custom_linter or any analyzer plugins.

When I run find . -type l -ls I get a long list of I suppose symlinks that probably just belong the the packages I use, for example:

111156169        0 lrwxr-xr-x    1 jonas            staff                  29 Mar  8 17:37 ./build/macos/Build/Products/Debug-platform/exercisable_flutter.app/Contents/Frameworks/FirebaseCore.framework/FirebaseCore -> Versions/Current/FirebaseCore

Is that anything out of the ordinary?

Here the screenshots of the "Timing" page:

[DanTup]

When I run find . -type l -ls I get a long list of I suppose symlinks that probably just belong the the packages I use, for example:

111156169        0 lrwxr-xr-x    1 jonas            staff                  29 Mar  8 17:37 ./build/macos/Build/Products/Debug-platform/exercisable_flutter.app/Contents/Frameworks/FirebaseCore.framework/FirebaseCore -> Versions/Current/FirebaseCore

Is that anything out of the ordinary?

That one doesn't look like a problem, but are there any that point back up the tree (eg. creating cycles or including other large parts of the disk in the the path)?

It may be useful to enable the analyzer instrumentation log (this file can get very large - be sure to turn it off afterwards) and reproduce the issue, and see if there is anything in the log file that looks out of place while this happens (for example exceptions, or paths you would not expect to be analyzed with this project open being analyzed).

You mentioned this only happens on large projects - are any of them public projects that I could test with (or that sharing logs from would not include anything sensitive)?

[JonasJW]

Hi @DanTup,

I apologize for taking so long to respond. I still have this issue and it's really slowing down my development process.

are there any that point back up the tree (eg. creating cycles or including other large parts of the disk in the the path)?

Here are a few symlinks, some point up but it doesn't appear to me that they would create a cycle

./windows/flutter/ephemeral/.plugin_symlinks/firebase_auth -> /Users/jonas/.pub-cache/hosted/pub.dev/firebase_auth-4.19.1/

./build/macos/Build/Intermediates.noindex/EagerLinkingTBDs/Debug/just_audio.framework/just_audio.tbd -> /Users/jonas/Documents/project_name/build/macos/Build/Intermediates.noindex/EagerLinkingTBDs/Debug/just_audio.framework/Versions/A/just_audio.tbd

./macos/Pods/Headers/Public/Firebase/Firebase.h -> ../../../Firebase/CoreOnly/Sources/Firebase.h

./ios/.symlinks/plugins/path_provider_foundation -> /Users/jonas/.pub-cache/hosted/pub.dev/path_provider_foundation-2.3.1/

./build/macos/Build/Products/Debug/FirebaseSharedSwift/FirebaseSharedSwift.framework/FirebaseSharedSwift -> Versions/Current/FirebaseSharedSwift

In total there are over 550 symlinks. Does any of this sound problematic?

I also tried the analyzer instrumentation logs but I can't really find anything that appears out of place. However, this document seems to log all kinds of stuff and I'm not sure how to analyze it or what to look for.

Yes, unfortunately, this project is private and can't be shared. I could probably share the analyzer instrumentation logs privately with you, if that would help.

I recently tested this project on a windows laptop and the issue occurs as well. (Thus, I think completely reinstalling my mac won't even help fix it).

These issues don't appear on new Flutter projects. Maybe I could try to download a big public project and see if I have problems with other bigger projects as well? If not it must be something specific with my project but I'm clueless about where the issue could be.

[DanTup]

In total there are over 550 symlinks. Does any of this sound problematic?

Nothing above looks like an issue to me - the issue would be if the link points further up the tree so that walking the tree could cause endless cycles.

I also tried the analyzer instrumentation logs but I can't really find anything that appears out of place

The most useful thing would be knowing what's being logged during the periods where performance is bad. So if the bad performance is during startup, it would be the start of the logs (until the first progress event with "kind": "end"). If it's during completion, it would be what occurs between the textDocument/completion request and the corresponding response.

Yes, unfortunately, this project is private and can't be shared. I could probably share the analyzer instrumentation logs privately with you, if that would help.

I can't accept anything confidential (instrumentation logs can contain contents of opened files and paths/errors for other files in the workspace), but if you're able to reproduce this on a copy of the project with anything confidential removed (and perhaps only a single test file open), you might be able to get a log that doesn't contain anything confidential you can share.

Something I forgot to ask earlier - can you confirm whether you have this option ticked in the VS Code (User or Workspace) settings?

[JonasJW]

Understood, I will go back to the logs and look for these progress events. If I have something to share I will follow up on it here.

The Dart: Only Analyze Projets With Open Files was disabled. I'm trying to enable it to see it that improves it, I will update you on this.

[DanTup]

The Dart: Only Analyze Projets With Open Files was disabled. I'm trying to enable it to see it that improves it, I will update you on this.

FWIW, my recommendation would be to not use that setting (and I should update the text). Although it sounds better for large projects, it was really added for a fairly specific case (command line editors that would provide the current working directory - which may be the user home dir - as the workspace folder). While the server will start up faster for very large workspaces, opening and closing files from different projects will trigger re-creating the analysis roots which can trigger "initial" analysis for those projects.

It's beneficial if you're opening a folder that contains 100 projects and maybe only opening files from a handful, but if you're jumping between a large portion of the projects in the workspace, it's probably worse overall.