Dart-Code: VSCode + Flutter + Dart => Rename Symbol is really slow and sometimes not even working
Rename symbol (shortcut key F2) in my flutter projects is really slow. Not sure if flutter is relevant of if this is a general dart problem. I think it is a dart problem so I’m posting here. When I have syntax/build errors I find it common that rename never finishes, the “infinite progress” in VS Code just keeps spinning what seems to be forever.
If I create a brand new (flutter) project: flutter create slow_refactor and then open the project, let everything initialize, pub get packages and let that complete as well. After this I go to main.dart, rename title to myTitle. This takes … 10? 15? seconds to complete. If I rename it to myTitle2 it takes a split second.
Can I mitigate this issue somehow? It’s really tedious to rename symbols and most often I just hit replace all feature instead because I’m convinced that the rename won’t work. Rename is such a common (simple) refactor that I expect it to work at all times.
I can’t find any known issues regarding this but I know that other members in my team have the same issue.
I’m running Windows 10, stable VS Code, flutter 1.13 and 1.14 (beta and master), dart 2.8.0-dev.3.0. My computer specs are category “great” so this is not due to slow cpu, disk or memory issues.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 44
- Comments: 45 (20 by maintainers)
This week I found a performance bug in the LSP server that may be related. The issue was a combination of a few things:
These things together can result in the server doing unnecessary work right when you’d want it to be doing other things (such as servicing a Ctrl+Click, or handling a file you’ve just opened).
The fix for that has landed in Flutter’s master branch. I wonder if anyone seeing these issues on is able to test whether temporarily switching to master seems to resolve this? (note: the first analysis of a project after changing branch will be slower, as the Flutter SDKs are seen for the first time). This appears to have helped for at least one user.
I’ve been examining this for the last couple of weeks and it seems like it’s some kind of “startup” work (just as you’ve stated above). After the first rename, the following renames are more or less instant. However, this startup does not trigger for me until the first rename. I can open my project, work for 30 minutes, build, debug, open/close files, create classes, hot reloads etc - then I rename a symbol and it takes a long time (7 seconds in the above case). So this “startup” work isn’t triggered until the first rename.
Our project is currently 95 dart files (300k in total size). An interesting observation is that even if I’ve been running the project for say 30 or 60 minutes and then I rename a class or a field - it will take at least the above 7 seconds. But sometimes it takes more (e.g. 20 secs) and sometimes (quite often) it does not complete at all. I guess it’s a timeout after 30 seconds or so? If a rename times out the loading spinner in VS Code stops moving and no error message or other info is displayed (and the symbol isn’t renamed). If I try to rename the same thing (or something else) after this, it renames immediately. We are currently three people working on this project, we all have the same issue. Currently we’re using the beta branch (1.14.6) but we’ve had this problem for quite some time. I would say around version 1 and including current master (1.15).
Another observation is that “References: Find all references” (Shift + Alt + F12) has the same issue. Finding references for a symbol can take really long time and it often times out. I guess this triggers the same kind of “indexing” job that rename uses.
A workaround that is working for me is to trigger “Find all references” with my morning cup of coffee and keep VS Code open during the day.
I’d like to repro this with a open source project so I can provide easy steps to reproduce and no problems sharing the logs (considering that the logs may contain info about our project). I don’t have time to do that right now but hopefully in a couple of weeks or so.
Sorry for late responses in for this issue!
@DanTup I run into this issue all the time as well. Freshly opened VSCode, everything works fine, but after 30-60 minutes of coding and hot reload work, the analysis server will come to a screeching halt. All intellisense becomes unresponsive or very delayed. It is weird because the problem gets resolved simply by closing VSCode and reopening. Same exact code will work just fine and analyzer will run through quick once I reopen. As I keep working, it will happen again and I need to close and reopen (just that, no other actions besides close/reopen).
So… I am wondering if it is related to something that the analysis server is caching? Does this sound familiar? Is there anything that the end user can change in the extension settings?
One more thing I will mention is that in the process of trying to see what the analyzer was doing, I enabled
dart.analyzerInstrumentationLogFile. Nothing stood out (not to me at least), but I did notice that this file would grow VERY quickly. By the time I am done with one of my sessions and noticing that the analyzer was slowing down, the log file would reach multiple GBs in size. Yes… that is GBs. I have since disabled that setting because eventually that file is impossible to open in any text editor. Just wondering if the analysis server is doing similar caching to what is in the log file and trying to parse through some ever growing cache which is why it slows down as you work?I have been trying to chase this issue for weeks. I saw something about the possibility that imports may be causing an issue for the analysis server. For example if the code base imports lots of libraries as opposed to single widgets from those libraries? I tend to break out my widgets into many file as
part ofa single library and import that entire library when it is needed. For context, this specific repo has alib/folder with 136 files. I suppose that is not “small” but it certainly is not unreasonable amount of files to house the source code of an entire app.Even if that was an issue, why does that only happen after some time in the analysis server, it does not manifest right away so there seems to be some link to amount of time the analysis sever is running (which is why I mentioned cache).
@DanTup any information or insight you can provide would be incredibly helpful! This has been driving me up a wall for quite some time and has really hampered productivity.
Hoping this helps. In this case, I restarted the server like @samandmoore mentioned, hit refactor (rename), and it seemed to hang for 8-10 seconds, so I did another refactor (rename) and it worked almost instantly. Not sure if there are any useful logs here, but there is traffic from the server. Perhaps something in the initial traffic to the server is indicative of the problem with the initial hang?
Logs
@walsha2 great, glad to hear! I suspect the issues were in the extension code that handles the auto-import completions (it has a lot of data to stitch together in each completion request) - it was definitely much slower in JS/node than the Dart server version is (though I hadn’t experienced it getting worse over time).
The goal is to move over to LSP by default gradually in the coming months (and ultimately have this be the only option) so hopefully it’ll become a non-issue in time. Thanks!
@DanTup thank you for the thorough response. I have been testing with
dart.previewLspenabled per your request and it has been night and day! I have not run into the same analyzer stalling issues I had in the past. I have worked in multiple hour long sessions and the analyzer was just as sporty at then end of the session as initial it was at initial VS Code launch. So that seems to have solved the issue I was seeing.I will refrain from opening a new issue at the moment, but I will keep an eye on it and open an issue with more details if needed. Thank you again!
@rydmike I don’t think the termination issue is related to this - I believe that’s a Dart watcher issue (discussion about this is in https://github.com/Dart-Code/Dart-Code/issues/2805).
Renaming multiple folders/multiple files is something on my radar. I have a working prototype, but it’s too slow (it enumerates all of the files and does the move refactor individually which scales quite badly). There’s an issue about this at https://github.com/Dart-Code/Dart-Code/issues/2483 though we also need some LSP spec changes (I have an open PR at https://github.com/microsoft/language-server-protocol/pull/1074).
I believe the issue here may be related to the file(s) being indexed, though I haven’t been able to reliably repro it with logging. In a future LSP release, refactors will show a progress notification so it will be clear that something is happening and it won’t just look like it silently failed (that doesn’t solve the issue, but is at least an improvement).
@walsha2
This sounds like a different issue to what’s being discussed here (which is just refactors being slow the first time - which I think may be related to files being indexed). Please file a new issue about this and we can figure out how best to debug (in the meantime, enabling the analyzer log file may be worthwhile, so when it next happens you can grab a copy and we can see if the time is being spent in the server or not). You should also grab the output of running
code --statusin a terminal which will capture the CPU + memory usage of all processes from the extension host to the analysis server which might be useful.If you haven’t already, I’d also recommend switching to LSP (“dart.previewLsp”) setting. This has several improvements in code completion that should improve performance.
Yep, this logs all of the communication with the language server in full and can be very verbose. The log file I mentioned above should be smaller (it truncates long lines, and overwrites on each new session) and would is a better option if you’re leaving it enable over a longer period (ofc it’s not quite as insightful as the instrumentation log).
I’m not aware of any performance implications of this (though I’m less familiar all of the internals of the analysis server), though 130 files doesn’t seem very large in my opinion so I’d be surprised if that was a source of performance issues.
We should continue this discussion in another issue though - it gets tricky tracking issues when there are many things in the same (if things turn out to be the same, it’s easier to close an issue as a duplicate than separate the info in a single issue to multiple). Thanks!
In my case, it seemed like the problem was with cache, because restarting the server and then renaming would take less than the rename attempt which caused me to search for this issue. I’ll keep a look on this.