zed

zed copied to clipboard

Check for existing issues

• [X] 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

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

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.

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.

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).

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)

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 (https://github.com/microsoft/TypeScript/issues/39459 has seen recent activity), it might be worth signalling your interest there by upvoting the issue.

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.

https://github.com/zed-industries/zed/assets/120525481/2746455e-2cce-4dcb-93cb-36f3a1634f73

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 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.

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.

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

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

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.

https://github.com/zed-industries/zed/assets/120525481/0642277d-e661-49ce-9406-d9903a3d81a4

To add onto my comment above, VSCode seems to still be faster in the initial fetch of suggestions. Zed does a better job of filtering them within the actual menu though.

I'm not 100% sure about this, as there could be other variables that affected the test. I literally just had both Zed and VSCode open side-by-side when doing this test.

VSCode had an initial fetch time of 1 - 3 seconds. Zed had an initial fetch time of 8 - 13 seconds.

To add on to the vscode vs zed comment, I don't observe this behavior in helix which is also using the lsp instead of vscode's tsserver setup

To add on to the vscode vs zed comment, I don't observe this behavior in helix which is also using the lsp instead of vscode's tsserver setup

Are you having this problem in a monorepo as well or just a regular repo?

To add onto my comment above, VSCode seems to still be faster in the initial fetch of suggestions. Zed does a better job of filtering them within the actual menu though.

I'm not 100% sure about this, as there could be other variables that affected the test. I literally just had both Zed and VSCode open side-by-side when doing this test.

VSCode had an initial fetch time of 1 - 3 seconds. Zed had an initial fetch time of 8 - 13 seconds.

I wonder if this is a monorepo specific issue? Have you tried opening one of the subrepos of this monorepo and seeing if there's still the large discrepancy?

To add on to the vscode vs zed comment, I don't observe this behavior in helix which is also using the lsp instead of vscode's tsserver setup

Are you having this problem in a monorepo as well or just a regular repo?

Just a somewhat large (<100kloc I think) repo. For reference a tsc takes around 10-15 seconds

To add on to the vscode vs zed comment, I don't observe this behavior in helix which is also using the lsp instead of vscode's tsserver setup

Just want to +1 this on our roughly 400,000 line (2600 file) project. Its one of the primary reasons I keep switching back to helix.

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?

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

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

Maybe all big repo (monorepo) could be used ?

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.

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 ?

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 https://github.com/microsoft/TypeScript/issues/39459. I think it's very funny/annoying that Microsoft's language doesn't support the protocol they themselves invented

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?

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.

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

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).

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