Extension slow to respond #1130
Comments
|
I did encounter a similar issue before. Still can't found out why, but it maybe is slowing down in the typescript language service part. It only pops up occasionally for me so this is not easy to debug. |
|
We're having major slowdown and often get a pop up saying that VSCode is waiting of the Svelte formatter. Some details Giving |
|
I publish a new version(105.3.4). Hope this would address the performance issues you're facing. |
|
That might have fixed it. Right now the file statistics do not grow as much as previously: |
|
I will have to revoke that statement.
After a while with |
|
Tried downgrading to version 105.3.1; it also has this problem. I think that i could work or Carbon projects without the freezes at some point. When I have some more time i could try to bisect the extension version, but any help in that regard would also be appreciated. |
|
Do you have a |
|
My tsconfig.json currently looks like this: {
"compilerOptions": {
"strict": true,
"moduleResolution": "node",
"target": "es6",
"lib": ["ES2020", "DOM", "DOM.Iterable"],
"sourceMap": true,
"importsNotUsedAsValues": "error", /* for svelte-preprocess */
"resolveJsonModule": true,
"allowSyntheticDefaultImports": true,
"allowJs": true,
"skipLibCheck": true,
},
"exclude": ["out/**/*"],
}I can also try to put together a repro repository later. |
|
You can try excluding node_modulus and build directories like |
|
This does not use sapper or svelte-kit. If i were to exclude that, i would lose the completion for that, though, right? |
|
carbon-icons-svelte have provided typescript definitions. So it's safe to exclude the source files. |
|
I tried excluding |
|
Did the slowness in any way creep back or can we close this? |
|
@dummdidumm Would be fine by me. Don't know about @stolinski's issue though. |
|
Hi, I'm also experiencing significant slowdowns with the latest version of the Svelte extension. I'm also using This is the process hogs my cpu and makes both VS Code and my entire system barely usable: I'd be happy to provide logs/dumps to help sort this out. |
|
I'd like to give more context because I suspect my issues are caused by our monorepo setup:
When looking at the output of the Svelte extension, I notice two possible issues:
We have many small packages, and the stats usually look like this: But then sometimes they look like this: I hope this long comment is helpful and I'd be happy to provide more info. My current setup is barely usable and I would really appreciate your help. |
Give certain requests priority. If a request doesn't have priority, we first wait 1 second to 1. let higher priority requests get through first 2. wait for possible document changes, which make the request wait again This hopefully makes perceived responsiveness of the language server better sveltejs#1098, sveltejs#1130, sveltejs#1139
Give certain requests priority. If a request doesn't have priority, we first wait 1 second to 1. let higher priority requests get through first 2. wait for possible document changes, which make the request wait again This hopefully makes perceived responsiveness of the language server better #1098, #1130, #1139
|
The latest release includes some performance improvements, for example completions should have higher priority now. Please let me know if it improved for you. |
|
Hi @dummdidumm, thank you for looking into this. I've added a settings and I'll share the output asap. The most notable slowdowns are when VS Code is waiting for code actions from the Svelte extension:
|
|
When you say "code actions" do you only refer to saving specifically, or other code actions as well? I guess while saving, you also format the code? What if you turn off "format on save" (if my guess is right; just for testing), is it then fast again? I ask this because the Svelte for VS Code extension by default is also responsible for formatting the code. Or do did you set the Prettier extension as the default formatter for Svelte files? |
|
I use this extension for formatting
Q: Should I only disable I haven't started coding yet so I haven't bumped into the issue, but I figured I would share the output of the extension after a clean open of the monorepo main directory with |
|
I just bumped into the problem: slow autocompletion (on |
|
Ok these diagnostics look like it has nothing to do with formatting, it's only the most visible then, because something else blocks the thread and the formatter is waiting to get started for a long time. From looking at the logs it looks like it may be the diagnostics that take so long. What if happens if you turn them off? If it is much faster, try turning only one off to see which diagnostic part takes longer. |
|
Big improvement!
|
|
The Prettier log is alright, it's a sign that the extension uses the referenced package for formatting. To be more specific: The Svelte extension uses Prettier to format the file, which is why, if you have The logs also seem ok. My guess now is that The TS plugin is unrelated to this issue. |
|
Thank you for the detailed explanation. I will keep Re open files:
Re preprocessors:
One question:
|
|
The newest VS Code extension (version 105.9.0) contains a performance improvement which should make global auto completions significantly faster, which should increase the overall responsiveness of the extension (and hopefully also improves the battery drain Scrott mentioned). Please provide feedback if it's better now. |
|
I used to have this issue last summer, then it got fixed. |
|
We didn't have any changes related to performance in the last two weeks, so that's strange. Some questions:
|
|
My apologies, I should have provided better feedback than that 🥲 I am not using the transformation. I have fixed my problem by changing my project dependencies packages versions...would have to pinpoint which one was causing the issue. Updated deps:
After making these changes, the extension is now working fine. |
|
I ran into this as well, but just only on large files, which at least around 1k lines. |
Same here with 1.5K lines: Did you manage to fix it? |
|
Instead of commenting "Same here," please provide information with the steps I commented earlier. |
What steps? I have |
|
I ran into the same problems as explained above, I use Tailwind, Prettier, EsLint, Typescript, SvelteKit. Versions I am using: Extensions are up to date, latest stable, OS is Linux |
Just for reference, to show which actions seem to take long. |
|
+1. Steps to produce:
I wish I could provide a better reproducable example but the project seems to need to be of sufficient size to trigger whatever rapid degradation in performance is occurring. As you can see from the log below, the code action takes 11 seconds to complete on an M1 Macbook Pro. Svelte may be trying to do too much work on its end rather than simply proxying to the TS server. The tsconfig explicitly ignores node_modules but they're showing up in the snapshot. Trace - 00:41:47] Sending request 'textDocument/completion - (5264)'.
[Trace - 00:41:47] Sending request 'textDocument/codeAction - (5265)'.
Using Svelte v3.56.0 from /Users/cm/ws/svelte-frontend/node_modules/svelte/compiler
[Trace - 00:41:48] Sending notification '$/cancelRequest'.
[Trace - 00:41:48] Sending request 'textDocument/completion - (5266)'.
[Trace - 00:41:48] Sending notification '$/cancelRequest'.
[Trace - 00:41:48] Sending request 'textDocument/inlayHint - (5267)'.
[ts] getCompletionData: Get current token: 0.004291057586669922
[ts] getCompletionData: Is inside comment: 0.018208026885986328
[ts] getCompletionData: Get previous token: 0.027250051498413086
[ts] getCompletionsAtPosition: isCompletionListBlocker: 0.00787496566772461
[ts] getExportInfoMap: cache miss or empty; calculating new results
[ts] getExportInfoMap: done in 16.80887508392334 ms
[ts] collectAutoImports: resolved 0 module specifiers, plus 0 ambient and 127 from cache
[ts] collectAutoImports: response is incomplete
[ts] collectAutoImports: 9.609333992004395
[ts] getCompletionData: Semantic work: 28.18766689300537
[ts] getCompletionsAtPosition: getCompletionEntriesFromSymbols: 4.0915000438690186
[Trace - 00:41:50] Received notification 'textDocument/publishDiagnostics'.
[Trace - 00:41:50] Sending request 'textDocument/codeAction - (5268)'.
[Trace - 00:41:50] Sending notification '$/cancelRequest'.
Using Svelte v3.56.0 from /Users/cm/ws/svelte-frontend/node_modules/svelte/compiler
Using Svelte v3.56.0 from /Users/cm/ws/svelte-frontend/node_modules/svelte/compiler
[Trace - 00:41:52] Sending request 'textDocument/documentSymbol - (5269)'.
Using Svelte v3.56.0 from /Users/cm/ws/svelte-frontend/node_modules/svelte/compiler
Using Svelte v3.56.0 from /Users/cm/ws/svelte-frontend/node_modules/svelte/compiler
Using Prettier v2.8.8 from /Users/cm/ws/svelte-frontend/node_modules/prettier
[ts] getCompletionData: Get current token: 0.004541873931884766
[ts] getCompletionData: Is inside comment: 0.023833036422729492
[ts] getCompletionData: Get previous token: 0.016124963760375977
[ts] getCompletionsAtPosition: isCompletionListBlocker: 0.001708984375
[ts] getCompletionData: Semantic work: 0.24299979209899902
[ts] getCompletionsAtPosition: getCompletionEntriesFromSymbols: 0.1382920742034912
[Trace - 00:41:57] Received response 'textDocument/completion - (5259)' in 13755ms.
[Trace - 00:41:57] Received response 'textDocument/codeAction - (5260)' in 12723ms.
[Trace - 00:41:57] Received notification 'textDocument/publishDiagnostics'.
[Trace - 00:41:57] Received response 'textDocument/semanticTokens/full - (5261)' in 12719ms.
[Trace - 00:41:57] Received response 'textDocument/inlayHint - (5262)' in 11725ms.
[Trace - 00:41:57] Received response 'textDocument/codeAction - (5263)' in 11479ms.
[Trace - 00:41:57] Received response 'textDocument/completion - (5264)' in 10208ms.
[Trace - 00:41:57] Received notification 'textDocument/publishDiagnostics'.
[Trace - 00:41:57] Received response 'textDocument/codeAction - (5265)' in 9960ms.
[Trace - 00:41:57] Received response 'textDocument/inlayHint - (5267)' in 8960ms.
[Trace - 00:41:57] Received response 'textDocument/completion - (5266)' in 9331ms.
[Trace - 00:41:57] Received response 'textDocument/codeAction - (5268)' in 7570ms.
[Trace - 00:41:58] Sending request 'textDocument/codeAction - (5270)'.
[Trace - 00:41:58] Received response 'textDocument/codeAction - (5270)' in 1ms.
[Trace - 00:41:58] Received response 'textDocument/documentSymbol - (5269)' in 6474ms.
[Trace - 00:41:59] Sending request 'textDocument/semanticTokens/full - (5271)'.
[Trace - 00:41:59] Received response 'textDocument/semanticTokens/full - (5271)' in 3msSnapshot SnapshotManager File Statistics:
Project files: 60
Svelte files: 52
From node_modules: 478
Total: 542Here's the tsconfig: |
|
Hey 👋 |
|
Could you post a link to a repository along with instructions in which file and how it happens so we can reproduce? |
|
Sorry for the late reply. I'll try to create a simple repo. |
|
@dummdidumm Editing any |
|
I cannot reproduce with your reproduction. I tried launching the Tauri app in dev mode and without dev mode. Do you have an instruction step to reproduce it? |
|
@jasonlyu123 The problem is during development while editing |
|
Yes. I know that. But I didn't see a significant slowdown. You might need to be more specific. Does it like slow down after you save a file? Create a new file? |
|
@jasonlyu123 |
|
Hello any updates on this? I'd like to add my own experience and reproduction steps of the symbol navigation lag in VS Code. Demo:
As shown here, it takes a while for the symbol navigator to load. In subsequent triggers to the symbol navigator there's no slowdown. But if you edit the file in any way, it slows down again. In comparison, here's how it looks like in Next.js:
Absolutely no delay. I tested this on a clean install of VS Code with the version:
Only the official Svelte extension was installed. Here's my VS Code config file: {
"svelte.plugin.css.diagnostics.enable": false,
"svelte.plugin.css.documentSymbols.enable": false,
"svelte.plugin.css.completions.enable": false,
"svelte.plugin.svelte.diagnostics.enable": false,
"svelte.plugin.typescript.diagnostics.enable": false,
"window.zoomLevel": 3
}I'm open to switching editors that doesn't have this issue in case this is a VS Code thing and not a language server issue. |
|
I've been encountering the same issue recently. I think one thing I noticed that no one else here has mentioned is that intellisense/autocomplete is only slow due to the HTML code in the same file. When I comment out the HTML code in my file, intellisense autofills become immediate. Maybe I'm just dropping total line number down, but it would also explain why .ts files have no problems. So to whoever is investigating this, the lag may be caused by whatever parsing/interpreting is happening between the JS in the <script> tag and the JS-bound HTML on the page. VueJS's Volar extension has a similar issue, I think, but there's got unusable much more quickly. For now, a "workaround" has been to comment out all of the HTML in a given file if I'm not actively working on it. I hope this get resolved at some point because I really don't to use webstorm. |
|
Please open a separate issue with reproduction on the problematic HTML. Usually, the ts/js part is much more heavy because the cross-file semantic analysis is needed. If I have to make a wild guess, it may be that your style tag or template preprocess is too heavy. |
|
Thank you, I've opened #2179 for that. I found the same performance hit happens even when there's no svelte variables/bindings in the HTML, which is interesting. |
|
Same issue. Super annoying |
|
Anyone of you guys managed to identify the problem? |
|
I came up with an extremely hacky workaround that seems to work. Basically, I write all of the JS in its own, non-svelte .js file. The intellisense for even huge files is fast. Then, I have a VSCode extension to run a node script whenever I hit save, which copies the contents of the .js file into the proper area of the corresponding .svelte file. So now I only touch the .svelte file when I'm writing HTML for it. I don't really recommend this approach unless you mostly edit the script section of your code and not your HTML (which is the case for me). It's also possible Svelte 5 doesn't have this issue at all? |
|
Agent mode in AI editors like Cursor fails 90% of the time in Svelte. It sees no lint errors after editing. Moments later, after it decided it finished w/ no errors, Language Tools then shows errors. Any such issues anyone? Tips? Writing more code in JS instead helps since the TS LSP is fast enough. |
Describe the bug
Getting auto-completion, symbol navigation or symbol information can be very slow (tooltip stuck on
Loading...).(It is probably the language server, because the profile from "Running Extensions" does not pick it up as causing CPU load.)
To Reproduce
Invoke commands like "Trigger Suggest" and "Go to Definition".
As for the conditions necessary to cause the slowdown, i am not sure. It may have to do with using
carbon-components-svelte/carbon-icons-sveltewhich introduce a lot of Svelte files.The "Output" panel shows this for Svelte:
Expected behavior
Language features are reasonably fast.
Screenshots
System (please complete the following information):
The text was updated successfully, but these errors were encountered: