Improve slow filtering of TypeScript autocompletions #5166
Comments
JosephTLyons
added
defect
|
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 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). |
JosephTLyons
added
javascript
|
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 (microsoft/TypeScript#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. Screen.Recording.2024-04-24.at.4.33.07.PM.mov |
|
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. |
Re filtering: this is already how Zed works. You can see that behaviour in the above video. The code is at |
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 |
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. |
JosephTLyons
added
the
autocompletions
|
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 Maybe all big repo (monorepo) could be used ? |
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 ? |
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 |
|
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 |
|
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. |
You can opt into using VTSLS instead of typescript-language-server by
pasting the following snippet into your settings:
```
"languages": {
"TSX": {
"language_servers": [
"!typescript-language-server",
"vtsls-language-server"
]
}
},
```
Related to: #5166
Release Notes:
- Added support for using [vtsls](https://github.com/yioneko/vtsls)
language server for Typescript/Javascript.
|
I believe I have a repro: can somebody experiencing this issue confirm that with the following project: |
Yes! This is exactly what I've encountered in the past! Very nice finding a reproduction case - legendary! |
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. |
|
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. |
Previously, we were: - cancelling previous requests only after the latest one has completed - always running the debounced documentation resolution to completion, even when we had no need for it. In this commit, we drop the ongoing completion requests as soon as the new one is fired. Fixes #5166 Release Notes: - Improved performance and reliability of completions in large Typescript projects Co-authored-by: Bennet Bo <bennet@zed.dev>
|
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. |
JosephTLyons
changed the title
|
To everyone who participated on this issue: Thank you 🙏 |
|
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? |
|
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 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 |
|
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 |
|
Sure, but again, this performance issue is specific to using TypeScript in Zed, it does not occur in VSCode. |
Check for existing issues
Describe the bug / provide steps to reproduce it
A user on Twitter wrote:
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.logfile to this issueNo response
The text was updated successfully, but these errors were encountered: