Improve slow filtering of TypeScript autocompletions

[JosephTLyons]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

A user on Twitter wrote:

I'm currently using Zed as my main editor, but the TS autocomplete performance is not there yet. It's slow and by the time I decide to choose an option from the autocomplete, it changes and I select the wrong thing.

Why is the TS performance so slow?

This is something I've experienced as well. Not sure if it's on our end or the language server's end, but results appear super slow; you can see them being slowly filtered down, after you have finished typing.

It seems that other editors using the TS server don't have as bad of performance issues as Zed has - which is strange.

Expected behavior

Environment

Zed 0.61.0 – /Applications/Zed.app
macOS 12.6
architecture x86_64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your ~/Library/Logs/Zed/Zed.log file to this issue

No response

[iamnbutler]

Yeah typescript language server in general seems not great. I have to restart it a lot and get a LOT of phantom errors.

[morajabi]

What happens for me is updates to the auto complete dropdown come in a burst and I have to literally wait a while until it stops changing. Seems like it isn't debounced properly.

[devongovett]

Did anyone figure out what's going on here? In large TypeScript projects I've noticed that the language server is constantly at very high CPU usage, leading to very poor autocomplete performance, hangs in go to definition and hover, and out of date diagnostics. This is not the case in VSCode, so I'm guessing that it isn't TypeScript itself but somehow the way Zed is interfacing with it. Maybe duplicate requests or something, not sure.

If you want a reproduction, clone the react-spectrum repo, run yarn, and then start editing some files. Everything is pretty laggy compared with VSCode.

I also noticed that it seems TypeScript specific, because the large Rust projects that I work on don't have this problem. Not sure if that helps.

[Aeolun]

I can confirm this. It's fairly aggravating to have finished typing the whole thing because autocomplete didn't show up, only to finally see it very slowly catch up after wards (I slowly see all the options I should've had before).

[Frank-vdm]

I dont know if this belongs here but i find the entire typescript experiance lacking, Its slow to pick up autocomplete, slow to recognise that imports have been added, the auto-import takes two or three tried before it knows what to import from where. errors take time to recognise that they have been fixed, and formatting with generics in React is not correct (same setup in VSCode works 100%, but in Zed commas that are expected are removed)

[synecdokey]

VSCode does not use an LSP for their typescript experience, so editors outside VSCode have had to rely on a community-driven package instead (https://github.com/typescript-language-server/typescript-language-server), but there's a lack of contributions that make it rather lacklustre in comparison.

You might have a better experience with another language server like vtsls (https://github.com/yioneko/vtsls), but the typescript team seems to be looking at supporting the LSP use-case (microsoft/TypeScript#39459 has seen recent activity), it might be worth signalling your interest there by upvoting the issue.

[x032205]

Here's a video of my experience on an M2 MacBook Air.

This is in a fairly large monorepo, and often times the autocomplete takes even slower than this to finish. Additionally, trying to click / select an option while it's still filtering results in an incomplete "artifact", with auto-imports not working.

Screen.Recording.2024-04-24.at.4.33.07.PM.mov

[11bit]

I tried to debug autocomplete a little bit. I suppose it is slow because Zed doesn't cancel previous request to LSP server but waits before it completed when text is changed. And so, when I type something I have to see autocomplete results for all the intermediate states before I get what I need

[x032205]

I tried to debug autocomplete a little bit. I suppose it is slow because Zed doesn't cancel previous request to LSP server but waits before it completed when text is changed. And so, when I type something I have to see autocomplete results for all the intermediate states before I get what I need

I'm not fully sure how the menu works, but it would be cool to see a combination of LSP request cancellations on query change + a front-end filter of the already fetched results.

This would make it so that while the new LSP request is being processed, the front-end would filter the client-side array of results from the previous request to give an instant filter feedback.

[keeslinp]

Yeah it is particularly frustrating when the value updates "underneath you" so you think you're getting the right thing and then it changes right before you hit enter and you autocomplete something else. Also every "tick" it resets your highlight to the top item so you can't nav down to the one you want and hit enter.

[babyccino]

I tried to debug autocomplete a little bit. I suppose it is slow because Zed doesn't cancel previous request to LSP server but waits before it completed when text is changed. And so, when I type something I have to see autocomplete results for all the intermediate states before I get what I need

I'm not fully sure how the menu works, but it would be cool to see a combination of LSP request cancellations on query change + a front-end filter of the already fetched results.

This would make it so that while the new LSP request is being processed, the front-end would filter the client-side array of results from the previous request to give an instant filter feedback.

Re filtering: this is already how Zed works. You can see that behaviour in the above video. The code is at Editor::selections_did_change

[babyccino]

Here's a video of my experience on an M2 MacBook Air.

This is in a fairly large monorepo, and often times the autocomplete takes even slower than this to finish. Additionally, trying to click / select an option while it's still filtering results in an incomplete "artifact", with auto-imports not working.

Screen.Recording.2024-04-24.at.4.33.07.PM.mov

Is this repo public? I want to have a look into this issue but I even the react spectrum repo runs fine on my m2 mba

[x032205]

Here's a video of my experience on an M2 MacBook Air.
This is in a fairly large monorepo, and often times the autocomplete takes even slower than this to finish. Additionally, trying to click / select an option while it's still filtering results in an incomplete "artifact", with auto-imports not working.
Screen.Recording.2024-04-24.at.4.33.07.PM.mov

Is this repo public? I want to have a look into this issue but I even the react spectrum repo runs fine on my m2 mba

Sadly no, the repo is private. We use TurboRepo with a NextJS front-end, as well as several analytic & backend processes running along-side it. The size of the repo is ~30mb.

I've tried to replicate the behavior I had in that video, and it seems like recent versions of zed have fixed it. I've attached a new video of handling a very large object for reference. With the new zed versions, it seems like there's the initial wait for the TS language server, and then after it looks like they just filter the results on the client itself. Overall I think this is a huge improvement.

Screen.Recording.2024-05-10.at.1.45.39.PM.mov

[JosephTLyons]

Does anyone have a way of reproducing this? It is not reproducible on my end, but maybe someone else has a repo that causes the issue faithfully?

[fdarian]

Was there any change related to this? It felt faster after I just switched back to Zed.

[Spoutnik97]

@JosephTLyons
I have one, but this is a private repo

Maybe all big repo (monorepo) could be used ?

[sebkolind]

Was there any change related to this? It felt faster after I just switched back to Zed.

I have the same experience as you. It definitely feels faster, but it still has some hiccups sometimes.

[Spoutnik97]

I wander why we can't use the vscode typescript server, knowing that vscode and typescript are open source

Is there something hard extracting the code from it ?

[babyccino]

I wander why we can't use the vscode typescript server, knowing that vscode and typescript are open source

Is there something hard extracting the code from it ?

See the comment above from synecdokey. Hopefully TS will eventually actually support LSP microsoft/TypeScript#39459. I think it's very funny/annoying that Microsoft's language doesn't support the protocol they themselves invented

[osiewicz]

For people who do see it, does it happen only once you spend some time coding, or is it reproducible for you with a given project regardless of the time spent?

[hos]

For people who do see it, does it happen only once you spend some time coding, or is it reproducible for you with a given project regardless of the time spent?

In my case, it happens after I spend some time coding.

[hos]

One more thing I forgot to mention, when I execute show autocomplete from command palette, it shows autocomplete correctly.

[osiewicz]

I've opened a PR that adds support for VTSLS. It should be available in the next Preview version on 5th of June. If you're eager to give it a try sooner (by building Zed from main), please feel free to.
I'm pretty positive it won't quite solve the problem, but any data point we can get for this issue is going to come in handy. If anybody here would be willing to pair to help track down what's going on, please reach out to me either via GH or Discord (my handle on Zed Discord is Piotr).

[osiewicz]

I believe I have a repro: can somebody experiencing this issue confirm that with the following project:
ts-completions-repro.tar.gz
Trying to autocomplete a variable from variables.ts inside index.ts shows similar symptoms to what you're experiencing?
All variables from variables.ts start with var. If you're unsure, you can use generate.py to generate it with a greater # of variables, e.g. 1000000

[JosephTLyons]

I believe I have a repro: can somebody experiencing this issue confirm that with the following project: ts-completions-repro.tar.gz Trying to autocomplete a variable from variables.ts inside index.ts shows similar symptoms to what you're experiencing? All variables from variables.ts start with var. If you're unsure, you can use generate.py to generate it with a greater # of variables, e.g. 1000000

Yes! This is exactly what I've encountered in the past! Very nice finding a reproduction case - legendary!

[sebkolind]

I believe I have a repro: can somebody experiencing this issue confirm that with the following project: ts-completions-repro.tar.gz Trying to autocomplete a variable from variables.ts inside index.ts shows similar symptoms to what you're experiencing? All variables from variables.ts start with var. If you're unsure, you can use generate.py to generate it with a greater # of variables, e.g. 1000000

Yep, that is exactly the issue I've been having, although I don't have that experience as much as I used to in the past. Not sure what changed, but something definitely got better.

[CedarMatt]

In my experience, I notice that the "correct" auto complete is presented to me right away then after some time (~1.5sec) the lagged typing results start to show up. When I trigger the autocomplete menu while not typing its always correct right away, presumably because I'm not typing. Feels like there is a queued de-bounced action pending from the keystrokes that isn't being canceled properly with the next keystroke. This is just a guess though without looking at the code too thoroughly.

[JosephTLyons]

This is now out in Zed Preview (v0.139) - please let us know if you are still hitting this issue, in or after that version.

[Greg-Hamel]

To everyone who participated on this issue: Thank you 🙏
This has just improved my Typescript workflow tremendously. It's the simplest of things sometimes.

[keeslinp]

Have people been moving to the vscode server or staying with the default one? I moved to the vscode and it seems way slower but I also don't have the bug described here anymore so maybe it is worth it?

[devongovett]

This is still an issue. I've tried both the default and vtsls (using zed 0.145.1), and both are extremely slow in our repo. While typing, the node process for the language server spikes to 100% CPU, and it continues for 10+ seconds after I stop typing, before finally updating the diagnostics in the editor. This does not happen in vscode, which is quite responsive.

If anyone wants to look into this further, please download our repo here and just try editing a file to introduce an error and fix it. It is pretty much immediately noticeable for me. https://github.com/adobe/react-spectrum

[Spoutnik97]

Have you tried to inspect your typescript performances ? You can be helped by this article : https://www.bajorunas.tech/blog/typescript-compiler-performance

I fix the tsc from 58s to 16s because I had 3 recursive types in my codebase

[devongovett]

Sure, but again, this performance issue is specific to using TypeScript in Zed, it does not occur in VSCode.

[baptisteArno]

Same issue @devongovett #18698

[iamnbutler]

I wander why we can't use the vscode typescript server, knowing that vscode and typescript are open source
Is there something hard extracting the code from it ?

See the comment above from synecdokey. Hopefully TS will eventually actually support LSP microsoft/TypeScript#39459. I think it's very funny/annoying that Microsoft's language doesn't support the protocol they themselves invented

Unfortunately, Microsoft has a vested interest in this not happening, as it locks people in to VSCode if they want the best typescript performance.