You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ctrl+Click on a symbol outside of your workspace is very slow #2873
Describe the bug
Hi @DanTup 👋
I am facing really slow plugin behaviour (Dart and Flutter). Generally, each and every action seems to be very slow.
I don't remember from when all this started, but maybe since last 4-5 releases, I am facing this issue.
Does this happen every time you do the action, or only the first time for each session?
Could you try enabling the Analysis server instrumentation log and reproduce the issue, then provide the log? (be sure to turn the logging off afterwards, as it can generate quite large files over long sessions).
Please invoke Go-to-Definition on the same thing multiple times while reproducing, so they're all captured in the log.
Does this happen every time you do the action, or only the first time for each session?
Difficult to tell. Sometimes, the Go-to definition is super-instant. Sometimes, it is slow even if done repeatedly.
The problem here is, this issue mostly (99%) happens with larger projects (around >150KB pure dart source), and it doesn't happen at all (but happens very rarely) in the sample Flutter app (flutter create something)
A side note:
Symbol renaming is still slow even in non-LSP mode (but with large projects only)
The slow renaming is being tracked in #2231, though I'm not sure if the slow Go-to-Definition is related (I initially thought so, but if that's happening only in LSP then it might be different).
Oh I see. This issue I am facing is bit more frustrating. One strange thing I found when Go-to definition is, if the file which contains the definition is already open, it does this instant (project size doesn't matter here).
But if the file is not open in editor, we get this slowness issue.
So, my primary assumption is that the analyzer does some heavy work while searching for definition.
This all does sound a lot like the other issue - which is that the index for those files is not built until the requests are made, and therefore it's slow. I'll keep this issue open, but may fold it into #2231 depending on what I find.
I agree on your assumption. The last issue I told (actions like wrap widget) are also taking 3-4 seconds to appear on non-LSP mode for the first time. After that, they are instant.
But in LSP, it takes around 5 seconds every time. So yes, this has definitely something to do regarding loading of these things.
How reliably can you reproduce the issue shown in the video above? Are there any files in your project other than those two? I'm trying with LSP and Dart SDK 2.10.0 but it's always instant. I tried with/without a pubspec, and with test1.dart open at startup, or closed. Cmd+Clicking always instantly jumps to test2.dart (it was not previously open).
If you can capture a log (see #2873 (comment)) while that happens, being able to repro here may help.
(If these files exist in another larger project, can you confirm if it only happens within the first few minutes of opening the project, or also after it's been open for a while?)
Let me know, if you want any additional information / logs.
One thing I noticed that, when I click the symbol (cmd+click), while it was loading, it showed me Analyzing... in the status bar.
Thanks - there's definitely something a little strange going on here. When you ctrl+clicked, VS Code sent quite a few requests, many of which were immediately cancelled:
It also sent a didOpen and then didClose immediately after each other (line 3+4 here) for a file, which makes no sense to me.
I'll do some testing here and see if I can figure out what it's doing. I don't know if it's the cause of the delays, but it definitely seems unexpected.
The first issue (the open/close events) appears to be a quirk of VS Code. I filed microsoft/vscode#109908 but then found that it was raised before (microsoft/vscode#84875) and the language extension had to work around it. Since we can't work around it for LSP (we don't control the client library) I've filed an issue about having the same workaround in the LSP client (microsoft/vscode-languageserver-node#683).
This is likely causing some of the problem, as it'll be triggering analysis (which contains synchronous work that will block the thread) before the navigation, which could then delay the navigation. If this was fixed, the analysis of the other file would not be started until after it's navigated to, which I think would solve it.
I'll try to repro all of the other requests being triggered though. They might be caused by the cursor moving while holding down ctrl, but I think they should be handled better (because we provide a range for the hover/definition).
I believe the slow Go-to-Symbol issue will be fixed by dart-lang/sdk@ddd70f5. VS Code is still sending the open/close events, but now they get filtered out better if they won't do anything (which is almost all of the time for a hover like that).
The other issue mentioned here (slow rename) is tracked in #2231 so I consider this resolved (although that fix isn't available in a stable Flutter release yet).
If you still see issues when using an SDK that includes the change above (which right now may be just the dev/master channels), please let me know!
Activity
DanTup commentedon Oct 13, 2020
Does this happen every time you do the action, or only the first time for each session?
Could you try enabling the Analysis server instrumentation log and reproduce the issue, then provide the log? (be sure to turn the logging off afterwards, as it can generate quite large files over long sessions).
Please invoke Go-to-Definition on the same thing multiple times while reproducing, so they're all captured in the log.
Thanks!
RaviKavaiya commentedon Oct 13, 2020
Okay, will do that and report you
RaviKavaiya commentedon Oct 13, 2020
@DanTup
The problem here is, this issue mostly (99%) happens with larger projects (around >150KB pure dart source), and it doesn't happen at all (but happens very rarely) in the sample Flutter app (
flutter create something)A side note:
DanTup commentedon Oct 13, 2020
The slow renaming is being tracked in #2231, though I'm not sure if the slow Go-to-Definition is related (I initially thought so, but if that's happening only in LSP then it might be different).
RaviKavaiya commentedon Oct 13, 2020
Oh I see. This issue I am facing is bit more frustrating. One strange thing I found when Go-to definition is, if the file which contains the definition is already open, it does this instant (project size doesn't matter here).
But if the file is not open in editor, we get this slowness issue.
So, my primary assumption is that the analyzer does some heavy work while searching for definition.
RaviKavaiya commentedon Oct 13, 2020
EDIT: One more performance related issue.
DanTup commentedon Oct 13, 2020
This all does sound a lot like the other issue - which is that the index for those files is not built until the requests are made, and therefore it's slow. I'll keep this issue open, but may fold it into #2231 depending on what I find.
RaviKavaiya commentedon Oct 13, 2020
I agree on your assumption. The last issue I told (actions like wrap widget) are also taking 3-4 seconds to appear on non-LSP mode for the first time. After that, they are instant.
But in LSP, it takes around 5 seconds every time. So yes, this has definitely something to do regarding loading of these things.
DanTup commentedon Oct 14, 2020
How reliably can you reproduce the issue shown in the video above? Are there any files in your project other than those two? I'm trying with LSP and Dart SDK 2.10.0 but it's always instant. I tried with/without a pubspec, and with
test1.dartopen at startup, or closed. Cmd+Clicking always instantly jumps totest2.dart(it was not previously open).If you can capture a log (see #2873 (comment)) while that happens, being able to repro here may help.
(If these files exist in another larger project, can you confirm if it only happens within the first few minutes of opening the project, or also after it's been open for a while?)
8 remaining items
RaviKavaiya commentedon Oct 30, 2020
@DanTup I am attaching a small debug log.
The steps I followed:
1). I just opened this project: https://github.com/flutter/samples
(The whole
samplesfolder in VS Code).2). Then, I opened these files:
1. https://github.com/flutter/samples/blob/master/veggieseasons/lib/main.dart
2. https://github.com/flutter/samples/blob/master/veggieseasons/lib/data/local_veggie_provider.dart
Only 2 files open, nothing else. Then I
closedthe VS Code and deleted the log files.3). Now, I opened VS Code. Waited for the analysis to complete. Again waited for few seconds.
4). Then, I just (
cmd + clicked) the symbol on this line: https://github.com/flutter/samples/blob/2165099fc95b8926a541a7a8f1dce35ba4501d1b/veggieseasons/lib/data/local_veggie_provider.dart#L17 (FromSeason.winterword, I clicked theSeason).5). Closed VS Code.
Let me know, if you want any additional information / logs.
One thing I noticed that, when I click the symbol (cmd+click), while it was loading, it showed me
Analyzing...in the status bar.dbg_analyzer.txt
debug_instrumentation.txt
DanTup commentedon Nov 3, 2020
Thanks - there's definitely something a little strange going on here. When you ctrl+clicked, VS Code sent quite a few requests, many of which were immediately cancelled:
It also sent a
didOpenand thendidCloseimmediately after each other (line 3+4 here) for a file, which makes no sense to me.I'll do some testing here and see if I can figure out what it's doing. I don't know if it's the cause of the delays, but it definitely seems unexpected.
DanTup commentedon Nov 3, 2020
The first issue (the open/close events) appears to be a quirk of VS Code. I filed microsoft/vscode#109908 but then found that it was raised before (microsoft/vscode#84875) and the language extension had to work around it. Since we can't work around it for LSP (we don't control the client library) I've filed an issue about having the same workaround in the LSP client (microsoft/vscode-languageserver-node#683).
This is likely causing some of the problem, as it'll be triggering analysis (which contains synchronous work that will block the thread) before the navigation, which could then delay the navigation. If this was fixed, the analysis of the other file would not be started until after it's navigated to, which I think would solve it.
I'll try to repro all of the other requests being triggered though. They might be caused by the cursor moving while holding down ctrl, but I think they should be handled better (because we provide a range for the hover/definition).
DanTup commentedon Nov 3, 2020
I was unable to repro all the cancelled requests, but I suggest we re-test this once the issue above is addressed to see how things are then.
[-]Plugin performance low (in LSP)[/-][+]Ctrl+Click on a symbol outside of your workspace is very slow[/+]DanTup commentedon Mar 1, 2021
I believe the slow Go-to-Symbol issue will be fixed by dart-lang/sdk@ddd70f5. VS Code is still sending the open/close events, but now they get filtered out better if they won't do anything (which is almost all of the time for a hover like that).
The other issue mentioned here (slow rename) is tracked in #2231 so I consider this resolved (although that fix isn't available in a stable Flutter release yet).
If you still see issues when using an SDK that includes the change above (which right now may be just the dev/master channels), please let me know!