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.

[mraleph]

@JonasJW what is your current experience with analysis performance? Are you still experiencing this weird behavior?

[JonasJW]

@mraleph yes, I'm still experiencing performance issues

[DanTup]

@JonasJW are you able to reproduce this issue with any public projects? It might be easier to narrow down with an instrumentation log, but that log will contain parts of source code from the open projects.

If it only occurs with this one specific internal project, is it possible to make a copy of it and see if you can narrow down what causes it (for example if it's made up of many packages, can you remove some of them to narrow down if it's caused by a specific package/set of packages)?

Do you also know if this issue occurs when typing in any file, or just some subset? This issue could be similar to #56307 which may be caused by the number of files that need to be reanalyzed as you modify a file (see #56307 (comment) and #56307 (comment)).

[amrgetment]

Maybe a related issue
Memory Leaks in the custom_lint library
invertase/dart_custom_lint#248

[larssn]

We have a pretty large project (internal, 200k lines), and this issue is pretty hard on productivity.

The worst of it comes from typing new class properties. The analyzer will get stuck on these for up to 20-30 seconds.

Here's my code --status and a screenshot of top memory in Activity Monitor.

Version:          Code 1.95.0 (912bb683695358a54ae0c670461738984cbb5b95, 2024-10-28T20:16:24.561Z)
OS Version:       Darwin arm64 24.0.0
CPUs:             Apple M1 Max (10 x 2400)
Memory (System):  32.00GB (0.28GB free)
Load (avg):       4, 5, 6
VM:               0%
Screen Reader:    no
Process Argv:     --crash-reporter-id 4e581022-c36a-4fd6-8d5e-12c2b8c113c3
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
                  webnn:                                  disabled_off

CPU %	Mem MB	   PID	Process
    0	   197	 47912	code main
    0	    98	 47915	   gpu-process
    0	    33	 47916	   utility-network-service
    0	   623	 47918	window [1] (sales_page.dart — tillty_pos)
    0	   492	 48349	extensionHost [1]
    1	    66	 48582	     electron-nodejs (config.js )
    0	     0	 48894	       /usr/bin/script -t 0 /dev/null /usr/bin/arch -arm64e xcrun xcdevice observe --usb
    0	    33	 48896	         /Applications/Xcode.app/Contents/Developer/usr/bin/xcdevice observe --usb
    0	     0	 48895	       /usr/bin/script -t 0 /dev/null /usr/bin/arch -arm64e xcrun xcdevice observe --wifi
    0	    33	 48897	         /Applications/Xcode.app/Contents/Developer/usr/bin/xcdevice observe --wifi
    6	  3736	 77823	       /Users/lars/Library/Android/sdk/emulator/qemu/darwin-aarch64/qemu-system-aarch64 -avd Pixel_Tablet_API_35
    1	    33	 77829	         /Users/lars/Library/Android/sdk/emulator/netsimd --host-dns=8.8.8.8,8.8.4.4
    0	    33	 48584	     /Users/lars/workspace/flutter/bin/cache/dart-sdk/bin/dart tooling-daemon --machine
    0	  1147	 48593	     /Users/lars/workspace/flutter/bin/cache/dart-sdk/bin/dart language-server --protocol=lsp --client-id=VS-Code --client-version=3.98.1
    0	    33	 48836	     electron-nodejs (languageserver.js )
    0	    33	 48880	     /Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Plugin).app/Contents/MacOS/Code Helper (Plugin) /Applications/Visual Studio Code.app/Contents/Resources/app/extensions/json-language-features/server/dist/node/jsonServerMain --node-ipc --clientProcessId=48349
    0	    98	 48350	shared-process
    0	    33	 48351	fileWatcher [1]
    0	    66	 59875	ptyHost

Workspace Stats: 
|  Window (sales_page.dart — tillty_pos)
|    Folder (tillty_pos): more than 20467 files
|      File types: transitive_digest(3880) class(1518) dex(782) xml(648)
|                  h(635) len(597) grpc_back(510) json(440)
|                  jar(368) c(325)
|      Conf files: launch.json(1) tasks.json(1)
|      Launch Configs: dart(5)

(The top consumer seems to be the Android Emulator, which is probably fine)

Here's the Dart process (if relevant):

Anything else I can do to help debug this issue?

[youssefali424]

Now i have to work without analysis at all in Vscode i dont understand why it's too slow in large apps, like shouldn't be there optimizations for this ? it was too slow before last flutter upgrade but now unusable at all

[crovax124]

unusable at the moment. This is really blocking us since the flutter 3.29

even if i put the old analyzer pre 3.7

it takes forever to code compete, the analyzing constantly needs to reanalyze everything. Same behavior as @marcov-dart

[marcov-dart]

I only have an issue when I use workspace resolution though. I have now reverted back to my old situation and then the problem goes away. The difference I could see is the difference in memory usage. Using workspace resolution pushes my computer 8Gb into swap. And then it is painfully slow (no surprise there).

[crovax124]

for us changing the resolution doesnt change anything. We downgraded to 3.27.4 until this is fixed

[kevtechi]

this still has a P2 after 1 year. it should be P0, it is urgent and it is a blocker for many of us. might as well use notepad to code without the analyzer.

[crovax124]

I think in 3.29.0+ its gotten unbearable

[vasilich6107]

@kevtechi there is a P1 one if it helps :-)
#60335

[bwilkerson]

@kevtechi I understand your frustration and I assure you that we are taking this issue seriously, despite the priority or the limited progress. I'm happy to increase the priority, and will do so after I finish typing this comment. One of the difficulties we're facing right now is an inability to reproduce the behavior you're seeing, but that doesn't mean that we aren't working on it.

[gisborne]

I am happy to do a screen share while you observe the behaviour on my machine.

[bwilkerson]

@mraleph Is that something we can do, and if so, would it be useful?

[amrgetment]

I am ok with that too

[mraleph]

@mraleph Is that something we can do, and if so, would it be useful?

We can not look at any code which is not public and properly licensed under an approved OSS license. This unfortunately makes it impossible to just observe users working on private code bases. That's why we need reproductions and other means to collect metrics.

[joachimbulow]

That's why we need reproductions and other means to collect metrics

I am not sure i can speak for everyone facing these issues, and i definitely hear what you are saying @mraleph, but this is, to me, not a hard-to-provoke issue which requires niche circumstances. From what i gather from the issues i read on this, it pretty much occurs after <1 hour of development time in a medium-large scale project, every single time. No matter if you are working on a new M4 Max or an intel Windows from 2018.

Which means, rather than requiring reporters to provide a consistent minimal reproducable example, you could just put your finger on the pulse and hop into a large scale environment for a while for some coding.

Perhaps you can gather from comments that using linting, using massive amounts of code gen, barrel files, whatever, might exacerbate the issue, this would only make it easier to experience yourself.

But once you inevitably face the issue, you would be able to perform an in-depth analysis with direct access to memory with analysers to collect metrics and statistics, using a more "anecdotal" approach than the reproducable example approach.

Just 2 cents, appreciate your efforts - i am sure this is a tricky issue to solve.

[gisborne]

Surely, if I put in writing that you’re allowed to see my code, we’re fine.

[bwilkerson]

... this is, to me, not a hard-to-provoke issue ...
... occurs after <1 hour of development time in a medium-large scale project ...

I'm not one of them, but we have people on our team that work on DevTools, which has around 3M LOC, and they aren't experiencing any problems. I don't know whether that qualifies as a 'medium-large' project, but it does suggest to me that there might be something more than just the size of the project that is required in order to cause the problem.

I don't, unfortunately, know what that is. It might be related to the OS, the IDE, a plugin, a builder, or almost anything.

Surely, if I put in writing that you’re allowed to see my code, we’re fine.

Presumably not. I assume it has to do with liability issues.

[gisborne]

The only thing that gives me pause wrt the IDE or its plugins is that the problem has been reported in both IntelliJ family IDEs and in VSCode.

Nevertheless, the plugins I have in IntellliJ that seem likely relevant are:

File Watchers
Rainbow Brackets
Ruby
Run Configuration for TypeScript
Swift Support
Windsurf Plugin
Full Line Code Completion and associated “Machine Learning Code Completion”, “Machine Learning Marketplace”, …

[bwilkerson]

Thanks, but I was thinking of analysis server plugins, not IDE plugins. The word is overused. :-/

[gisborne]

dev_dependencies:
build_runner:
custom_lint:
dart_format:
flutter_launcher_icons:
flutter_lints:
flutter_test:
sdk: flutter
very_good_analysis:

[DanTup]

@gisborne custom_lint includes an analysis server plugin so I suspect you're hitting the issue described in #60335 (comment).

It would be useful to know if your issues go away if you temporarily disable custom_lint or test with the SDKs noted in that comment. If so, hopefully your performance will return to what it was before once that fix rolls out.

[saropa]

It would be useful to know if your issues go away if you temporarily disable custom_lint or test with the SDKs noted in that comment. If so, hopefully your performance will return to what it was before once that fix rolls out.

Just to jump in, we're not using custom_lint at all. Nor are we using build watchers any more (e.g. dart run build_runner watch --use-polling-watcher).

Even the switch away from VS Code and disabling all except critical flutter extensions did not resolve the issue. Analyzer and / or dart-fix are slow to the point where intellisense is effectively unavailable. "Applying code action 'Fix All'." is almost always visible during coding.

[jensjoha]

Please follow #55281 (comment) and post the data requested.

[saropa]

Sure. The attached was caputured when simply adding and then removing a bool parameter to a static utility method.

dart_analyzer_diagnostics_report.json

And then renaming a static util method.

dart_analyzer_diagnostics_report2.json

Not sure how to parse, so may not have captured correctly.

PS. I do appreciate it only seems to be occuring in only a subset of your environments, and that is frustrating. But I do hope there are material resources allocated to a fix for the next release, as the costs are mounting up.

[joachimbulow]

One thing i have started to notice is that the issue seems especially exacerbated when my laptop has gone into a locked / sleeping state with the analyzer (and app) running, and i wake it to continue working.
(Laptop not at all otherwise slow btw)

[jensjoha]

@saropa Thanks.
You're using Dart 3.7.2 which has a known regression (#60335) that I believe is fixed in 3.7.3. With the comment

"Applying code action 'Fix All'." is almost always visible during coding.

I believe what the bug will, in your case, result in, is that the analyzer will stop processing requests until the "Applying code action" has finished. E.g. from one of the reports you uploaded (I reversed the order here so it can be read from the top):

    {
      "id": 23082,
      "operation": "textDocument/codeAction",
      "requestLatency": 4,
      "elapsed": 5,
      "startTime": "2025-05-05T13:39:25.054903",
      "performance": "(name: request, count: 1, elapsed: 0:00:00.005803, elapsedSelf: 0:00:00.005371)\n  (name: ServerDartActionsComputer.getSourceActions, count: 1, elapsed: 0:00:00.000430, elapsedSelf: 0:00:00.000430)\n  (name: PluginActionsComputer.getSourceActions, count: 1, elapsed: 0:00:00.000002, elapsedSelf: 0:00:00.000002)\n"
    },

Here everything is good, low latency and fast response time.

    {
      "id": 23083,
      "operation": "workspace/executeCommand",
      "requestLatency": 4,
      "elapsed": 2576,
      "startTime": "2025-05-05T13:39:25.066930",
      "performance": "(name: request, count: 1, elapsed: 0:00:02.576519, elapsedSelf: 0:00:02.576358)\n  (name: IterativeBulkFixProcessor.fixErrorsForFile, count: 1, elapsed: 0:00:00.000161, elapsedSelf: 0:00:00.000011)\n    (name: BulkFixProcessor.fixErrorsForFile pass 0, count: 1, elapsed: 0:00:00.000150, elapsedSelf: 0:00:00.000019)\n      (name: getResolvedLibrary, count: 1, elapsed: 0:00:00.000131, elapsedSelf: 0:00:00.000131)\n"
    },

Here a 'fix all' (or something) is executed. For whatever reason it takes more than 2.5 seconds. That's probably an issue on its own, but it causes:

    {
      "id": 23084,
      "operation": "textDocument/inlayHint",
      "requestLatency": 2580,
      "elapsed": 2,
      "startTime": "2025-05-05T13:39:27.643954",
      "performance": "(name: request, count: 1, elapsed: 0:00:00.002721, elapsedSelf: 0:00:00.002721)\n"
    },

this next request to be delayed by the same 2.5 seconds, or said another way, the analyzer becomes compeltely unresponsive for ~2.5 seconds. At the same time the number of requests might build up exacerbating the issue because it will take longer to catch up.

Unfortunately Dart 3.7.3 is still to make it to Flutter Stable. You could perhaps try follow #60335 (comment) (maybe using official Dart 3.7.3 from https://dart.dev/get-dart/archive instead of @mraleph custom builds).

All that being said, modifying the application in a way that changes the outline (e.g. if removing a bool parameter to a method or renaming a method) will naturally kick off a lot of recompilation. Experimental work is in progress (e.g. #60293 (comment)) but will take time.

[jensjoha]

One thing i have started to notice is that the issue seems especially exacerbated when my laptop has gone into a locked / sleeping state with the analyzer (and app) running, and i wake it to continue working. (Laptop not at all otherwise slow btw)

Interesting. Could you provide logs (#55281 (comment)) with an example of that?