Incredibly slow imports in Svelte & SvelteKit projects.

[takoyaro]

Describe the bug
The Language server is extremely slow when importing packages in both Svelte 3 projects as well as SvelteKit projects with or without Typescript enabled. Works lightning-fast in non-Svelte/SvelteKit projects.

To Reproduce
Importing any component or npm package.

Expected behavior
I'm expecting a response in milliseconds.

Screenshots
In a Svelte Project:

sveltelangserver3.mp4

In a non-Svelte project:

normalts.mp4

System (please complete the following information):

• OS: Windows 10 v2004
• IDE: VSCode 1.56.2
• Plugin/Package: "Svelte for VSCode"

[jasonlyu123]

Can't play the video. Can you provide a text description of what exactly is slow? Is it import path completion or auto-import completion?
If it's import-path completion we are working on it. But no ETA on it as there might be multiple causes with it.

[takoyaro]

Hey @jasonlyu123 , it is indeed the import-path completion.
Since you can't view the videos, I'm attaching the videos as gifs below just for the sake of keeping a record.

Svelte/SvelteKit Projects:

Normal Typescript projects:

[jasonlyu123]

#1015 would likely address part of this if you have some not resolvable import in the codebase. For example, CSS, file import, or svelte import without the file extension.

[dummdidumm]

Two more problem sources:

• diagnostics are called too often / not only on the latest state.
• both . and / are trigger characters which run the completions. If the completion takes too long, that adds up because they are processed in order. We somehow have to skip running old completion requests, but that would likely involve some kind of debouncing, which might hurt DX in other places where we wait for "no reason". Some quick tests showed though that the completion seems to be much faster if we debounce a little, likely because the work of synchronizing the changes also takes time.

[jasonlyu123]

tssever is likely to use a cancellation token to cancel the request. And the LSP also has a cancellation mechanism.

So I tried to hook up the cancellation token of the LSP to the cancellation token of the typescript. I found that we need a file-system-based implementation to work. Because typescript language service is synchronized. And node.js is single-threaded. So the cancel message of the LSP won't be able to cancel the synchronous ts code.

What I mean by file-system-based is that client written a temporary file into the file system. And the sever can check if the file exists to know if the request is canceled. That means we have to identify which file is meant by which specific request.

With vscode-languageserver 7.1 next 4, I at least managed to cancel the request in the asynchronous part of our code.

I'll create a PR next week for the asynchronous cancellation approach. And we can think about the synchronized cancellation in the future.

[dummdidumm]

Another thought: I think that the TS language service calls some kind of "synchronize program" method before he does the actual work. If so, we could check how long that synchronisation takes time, and if it's relevant, we pull out that part and do it ourselves, then wait for a tiny bit and then check if there's a new request, and if so return early.

[dummdidumm]

Could you try again with the latest version? That one hopefully made this one more performant (although there certainly is still room for improvement)

[takoyaro]

Could you try again with the latest version? That one hopefully made this one more performant (although there certainly is still room for improvement)

Absolutely life-changing improvement, I have no words. Thanks a lot for your help!!

[dummdidumm]

Glad to hear that, I'm going to close this issue then (@jasonlyu123 you can still open your asynchronous cancel PR if you want to).