performance - very slow compared to tsserver

[prabirshrestha]

Even an empty project takes for ever to show completion results. console. and window. took almost 5 sec but 'hello'. was immediate. The first time I could expect console. to be slow but even the second time I run type console. it seems slow. I would had also expected the completion to show as I type c in console but the results are so slow that it doesn't show.

[felixfbecker]

Would be interesting to see a trace for this

[damieng]

Also seeing this slowness using my Atom package. Does your vim plugin support streaming? I'm wondering if the non-streaming/partialResults versions are that much slower/stacked behind all the partialResults.

Seeing about 7 seconds to resolve super. with only one level of classes. Subsquent updates are initially a bit faster but then if I backspace it takes some time to get alternative completions.

(Windows, using stdio communication)

[prabirshrestha]

It follows strict protocol so no streaming or partial results.

I’m also using stdio on windows.

[prabirshrestha]

Uploaded the log but don't think it will be useful since it doesn't have timestamp. https://gist.github.com/prabirshrestha/fe19248df64de14260d977c42bcdf16c. Also might be good to include the OS, version and the protocol used in the log. Let me know if you still want me to share vim-lsp log which is more verbose.

vim-lsp doesn't support streaming and this could be the root cause of why the completion is being ignored and not shown. Tailing the log I do see partial results come fast.

Given that stream still hasn't been merged to the official protocol I would want to avoid implementing stream in vim-lsp as I would like to get other features first. I also want to avoid writing JSON patch in viml for now.

Support for this method is indicated by the streaming capability in both ClientCapabilities and ServerCapabilities.

https://github.com/sourcegraph/language-server-protocol/blob/streaming/protocol.md#partialResult

Based on the above spec currently when vim-lsp passes capabilities: {} it shouldn't return partialResults. So this would still be a bug in lang server.

[damieng]

The sending of partialResults when not supported by the client has an issue at #329

[felixfbecker]

Before we jump to conclusions, can you try to comment out this line and see if it changes anything?
https://sourcegraph.com/github.com/sourcegraph/javascript-typescript-langserver@master/-/blob/src/connection.ts#L261-269

[damieng]

I actually have a patch on mine that puts a if (streaming) block around there. It stops the partialResults sending but it still takes a long time to process.

I have in my small 1 javascript project a const path = require('path') a few lines later in a method I typed path. and saw the textDocument/completion request go out.

It took almost 14 seconds to receive the 31 item array back for the path import. (This was on my mac)

[damieng]

Just did some more testing. I think what's happening is that firing the autocomplete for every keystroke is causing a backlog as the scope for that is wide. If i turn off autocomplete-on-keypress and then just manually trigger the autocomplete request manually performance is much better.

[felixfbecker]

Does neovim look at the isIncomplete value? If it's false, it shouldn't send more requests

[damieng]

Sorry, I'm using my Atom bridge not neovim. We're sending a fresh request for completion on every keystroke effectively. (so it provides autocomplete for variable names etc).

[tomv564]

I turned off completion on all keystrokes, just have it on what the server advertises ('.'). Is there debouncing logic on your keystroke trigger?

[prabirshrestha]

I can try @felixfbecker suggestion tonight on commenting partial requests and verify.

I'm using asyncomplete.vim with vim-lsp to provide autocompletion for lang server. It doesn't send completion requests on every keystroke. It does respect isIncomplete flag and will only make requests if it is true.

asyncomplete.vim and nvim-completion-manager uses similar algorithm as VsCode for autocomplete which I have written about it at roxma/nvim-completion-manager#30 (comment). It is really good at caching. Might be atom plugin could implement similar algorithm? There is also an active issue on LSP on how triggerCharacters. microsoft/language-server-protocol#268

I also have written my own implementation of the typescript language server that acts as a proxy for tsserver.cmd which I will try to open source tonight. Currently only implemented textDocument/completion. I didn't have any issues with the perf there even for large codebase.

[damieng]

Drastically reducing how often we called completion has solved problems on Atom. Now we just trigger it on . and when manually requested.