Dart Analyzer very slow/stuck #55281
Comments
keertip
added
type-performance
|
@DanTup , do you see this? Have there been more reports of this kind? |
|
/ cc @bwilkerson |
|
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:
|
|
We were having the same issue and using the 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 ? |
|
/cc @scheglov |
keertip
added
P2
|
@DanTup Thanks for the response and sorry for the late reply. code --status output: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. |
|
For us updating |
|
@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 You should be able to check for symlinks by running |
|
@DanTup thanks for the clarification! I don't use When I run Is that anything out of the ordinary? Here the screenshots of the "Timing" page:
|
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)? |
|
Hi @DanTup, I apologize for taking so long to respond. I still have this issue and it's really slowing down my development process.
Here are a few symlinks, some point up but it doesn't appear to me that they would create a cycle
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. |
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.
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
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?
|
|
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 |
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. |
|
@JonasJW what is your current experience with analysis performance? Are you still experiencing this weird behavior? |
|
@mraleph yes, I'm still experiencing performance issues |
|
@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)). |
|
Maybe a related issue |
|
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 
(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? |
|
One request (to @luis901101 specifically but also to everybody else): please keep any Flutter 3.29 / Dart 3.7 related content in the 3.29 issue. If you are relatively happy with analyzer performance but experienced problem with Flutter 3.29 / Dart 3.7 - go to #60335. We are already piling too many things into this issue and it is becoming a kitchen sink. Everything that has clear root cause - we fork discussion into a specific issue and keep it there. Only generic reports (which have not been triaged to a specific root cause) should remain here. Thank you for understanding. |
|
@mraleph should I move my last comment to the other issue? |
|
@luis901101 I think it is okay to keep it here. |
|
I've been using the test version and if anything, it's slower. I fixed a minor type issue over a minute ago, and I'm still seeing the red squiggle shrapnel and the Dart Analysis window is still showing the error. Sometimes, it gets stuck and never notices that I've fixed something. I find myself restarting analysis every five minutes or so.
|
|
I'm really tired of having to work out relative paths for writing manual imports. Automatic imports does not, afaict, work at all, ever for me. |
|
@gisborne Is the problem you're experience a regression in Flutter 3.29, or is this an issue you've been seeing since before 3.29? Just trying to establish how many performance issues we might have. Also, could you open the server diagnostics pages, select the "Collect Report" tab, generate a report and send it to us (after reviewing the data to ensure that we didn't accidentally include any personal or confidential information in it)? Thanks. |
|
I've been having such problems for some time. A year, maybe? Happy to do a screen share or something while we do diagnostic things, if that would help. hmu To be clear: it has gotten significantly worse now. The analyzer is slowing me down significantly — particularly when it doesn't offer to write import statements for me. |
|
Are you using workspace resolution by any chance? I thought it was neat and decided to use it. But things got unusably slow. It would analyse for minutes and then after every small change it would analyse again. I press 2 keys and there it goes again. Memory usage was at 13.8 Gb. I just reverted back and now it is at 3.4Gb when I load my big workspace. It still needs time (a minute or so) to analyse after I open my workspace but not nearly as long and it stopped needing to analyse again and again after ever small change. |
|
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 |
|
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 |
|
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). |
|
for us changing the resolution doesnt change anything. We downgraded to 3.27.4 until this is fixed |
|
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. |
|
I think in 3.29.0+ its gotten unbearable |
|
@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. |
bwilkerson
added
P1
|
I am happy to do a screen share while you observe the behaviour on my machine. |
|
@mraleph Is that something we can do, and if so, would it be useful? |
|
I am ok with that too |
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. |
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. |
|
Surely, if I put in writing that you’re allowed to see my code, we’re fine. |
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.
Presumably not. I assume it has to do with liability issues. |
|
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 |
|
Thanks, but I was thinking of analysis server plugins, not IDE plugins. The word is overused. :-/ |
|
dev_dependencies: |
and others
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:
I'm on macOS 14.4, VSCode Version 1.87.2 (Universal),
In the Activity Monitor, there is the
dart:analysis_server.dart.snapshotprocess 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 infooutput:General info
Project info
Process info
Any recommendations on how I could possible fix this would be very welcome!
The text was updated successfully, but these errors were encountered: