[Request for info] open performance work

[marcelbeumer]

Hello team, first of all thanks for putting all that work in typescript-language-server.

I'm opening this issue as a "request for information". Tldr: could you describe all open performance topics so contributors can easily pick topics up and submit PRs?

AFAIK, since day and age, this LSP gives a slower experience than the non-LSP compliant tsserver experience you get with VsCode. Microsoft does not want to provide a LSP spec complient lang server (microsoft/TypeScript#39459; my free interpretation of their lack of progress here). I personally use neovim, and combined with the nvim-cmp autocompletion plugin, in many codebases the performance is fine for me on my M1 Mac, but some others I notice the difference in performance. For example, try adding the aws-sdk package to your project and see how slow autocompletion gets (even VsCode will get slower; but performs better).

I remember neovim contributers say typescript-language-server is one of the slowest out there, something with returning too many results, and not being the fault of the authors because it's also due to working around tsserver, but not sure if that is still true.

If I can, I'd love to see if I can contribute, because I don't want to switch editor for codebases that get slow with the lang server.

I imagine having a set of well described issues with a "perf" label of sorts would help jumping in!

[rchl]

I'm not aware of any performance issues yet to be solved, to be honest, but I have some thoughts.

VSCode by default runs two instances of tsserver and splits requests between the two. You can set "typescript.tsserver.useSyntaxServer": "never" in VSCode to make it only use one and then compare the experience. It would be useful to know how much closer the experience gets to neovim then.

Also, VSCode doesn't have to deal with the LSP communication since it skips that layer and directly interacts with tsserver. I imagine this sholdn't really have much impact but it could, depending on the editor. Maybe some are worse with parsing big JSON responses than other. It could have significant impact if editor is slow in processing JSON data since auto-completion responses can be a couple megabytes big if "auto-import" feature is enabled.

And also related to completions, large number of completions (sometimes thousands in case of tsserver) can be handled in a more or less performant way depending on the editor. For example in Sublime Text we have an issue that when typescript-language-server comes up with thousands of completions, it can can cause slight lockup of the UI for 200ms or so, depending on the system. On top of that, ST doesn't provide us a way to cancel completion request when user is typing fast and triggering multiple requests one after the other which can also affect perceived speed.

Speaking of canceling request, this server doesn't always implement support for those wheres VSCode does it more consistently. If your editor supports canceling requests and you are testing by changing document quickly then it could have some impact.

So with all that said, it's not easy or fair to compare behavior of certain editor + this server vs. vscode + builtin typescript service because the performance and supported LSP functionality of the editor itself can vary.

Support for running multiple instances of tsserver is planned but it's not clear whether it would help your specific case.

What you could also try is instead of using this server you could try using @yioneko's https://github.com/yioneko/vtsls which should be very close to VSCode's code base functionality-wise and check if you see improvement then.

[yioneko]

I'm also an nvim user and faced the same problem. Probably my situation is much worse than you because the server is nearly unusable for one of my scarily large project.

I tried to deeply troubleshoot the problem months ago. Generally my conclusion is the same as #327. The biggest performance killer is the semantic check for diagnostics, as the tsserver doesn't have any cache mechanism for it and recalculate all relevant semantic diagnostics on every GetErr request. Note that the request is triggered on every textDocument/didChange. Although the server already debounced it, 200ms is far from ideal for my case. The problematic project I worked on causes delay of 4s or so for a single request of diagnostics. Even worse, there is an accidentally removed line in commit b9cf578 which should cancel pending diagnostics request for faster response.

Also, the server doesn't use cancellationToken for every language feature method, such as textDocument/completion, where workspace/executeCommand has but doesn't use it for tsserver request. What this means is that the requests already sent to tsserver (not typescript-language-server itself) will not be able to get cancelled on $/cancelRequest.

The responsiveness did improve a lot after I applied the above fixes and set the diagnostics debounce to 4000ms locally. These might be useful hints for you to explore the performance issue.

I decided to develop vtsls later mainly because I wanted the missing features in VSCode (although some of them are implemented recently for this server) and maintainability. Catching up with another project is hard, some basic code in this server could be dated back to many years ago while that in VSCode has changed thoroughly. If you want to use some features like separate server or workspace diagnostics, you can try it and I've tested it well with nvim-lsp. There is also nvim-vtsls for quick setup specifically in nvim.