Improving Perf

[prabirshrestha]

Top request for vim-lsp 2021 was to improve perf.

Before I start working on this I would like to hear specific on what users are seeing. For example: vim-lsp is slow when autocomplete is enabled but ok when disabled, diagnostics is slow. LangServer X is slow. More details I can get on languageserver/filesize/number of lines or sample repo it will help me more.

#1020 (comment)

@timsofteng feel free to provide more details here.

[sparkcanon]

Let me start by thanking you for your work on this plugin and also to all the contributors.

As a preface, I don't really think vim-lsp is particularly slow compared to any other LSP plugin I've tried. Some potential areas of improvement could be as follows in my opinion.

The below is based on a project with about 15k loc with vim8.2.2300. I am using typescript-language-server and eslint-language-server/diagnostic-languageserver in combination on a node project.

1. The autocomplete has a slight delay after a few characters are inserted. This has already been mentioned, I suppose.
2. I've tried vim-lsc and Neovim's built-in LSP comparing them to vim-lsp, I couldn't really tell a difference in start-up times to be honest. Although Neovim's built-in LSP does appear to be ever so slightly faster, this is in mere milliseconds and not really noticeable (at least to me). This could be an area of further improvement.
3. There's a slight delay in signature help as you insert and this can sometimes lead to non-responsiveness for a millisecond as you try to insert the consecutive arguments.

[prabirshrestha]

1. The autocomplete has a slight delay after a few characters are inserted. This has already been mentioned, I suppose.

This is expected since autocomplete is async and langservers may reply later. If you are using asyncomplete it lot smarter at caching similar to vscode which other vim autocomplete plugins have also followed. I'm curious if this has caused delay or your vim is actually freezing for few sec or milliseconds. When I had looked into this several months back, freeze was primarily due to converting lsp completion items to vim completion items. VimScript is slow in general but even worse when using forloop. You could enable logs and see how many results you were getting from completion items. Any time you have more than 250+ items (which is very common in lsp) and you need to loop in vimscript you can notice the freeze. My hope is to convert this bottleneck to lua and see if we can get 5-10x perf improvements as we did with other code. I'm hoping the lua/vim boundry conversion will be cheap enough.

Make sure your vim has lua support which you can verify with has('lua') and has('patch-8.2.0775) or neovim 0.4+. This can drastically improve flushing performance by 6x to 8x compared to vimscript.

Make sure you have vim with exists('*matchfuzzypos') and fuzzy matching enabled in asyncomplete. this avoids using vimscript's for loop and directly goes to using loop implemented in c and can have a huge perf gains. Neovim doesn't support this yet but is currently in PR.

2. I've tried vim-lsc and Neovim's built-in LSP comparing them to vim-lsp, I couldn't really tell a difference in start-up times to be honest. Although Neovim's built-in LSP does appear to be ever so slightly faster, this is in mere milliseconds and not really noticeable (at least to me). This could be an area of further improvement.

Neovim will always be faster that vim-lsp due to lua and how neovim is modifying their functions to understand lua objects. Unfortunately vim will most likely not be taking these changes. vim-lsp was designed to be proof of concept as well as convince many people how awesome lsp is in the vim community. it was really designed for adding features and accuracy instead of perf. The good news is that there are lot of perf improvements that we can do in vim-lsp which I had explicitly ignored. My goal is to make vimscript faster and then migrate to lua for even faster speed.

There are also lot of other ideas I have for vim/neovim that could use to make it faster so that I can optionally depend on new apis for faster perf.

There's a slight delay in signature help as you insert and this can sometimes lead to non-responsiveness for a millisecond as you try to insert the consecutive arguments.

I'm not sure what you mean by non-responsiveness, is this vim freezing or that vim is responsive and just takes time to show the signature. Signature help doesn't seem to have cutomizable timers. Can you try changing timer_start(500 to a value you would like too. Feel free to send a PR to customize this.

I have been using Typescript codebase for some of the perf profiling but is only 5k lines of code. If you have examples of open source projects that have 15k lines of code or higher let me know and can use it to profile.

[prabirshrestha]

Please try https://github.com/prabirshrestha/vim-lsp/tree/completion-perf branch. I have made some perf improvement primarily related to autocomplete. For best perf you need vim with lua that has exists('*matchfuzzypos')

[brookhong]

Thank you very much for your work on this plugin, I do feel the performance of this plugin is worse when comparing with neovim/nvim-lspconfig, I can see obvious latency on actions like go-to-defintion or completion. Meanwhile we must acknowledge that neovim does improve performance a lot.

Please see my screen recording -- Performance differences between nvim-lspconfig and vim-lsp from prabirshrestha - YouTube, which was recorded working with eclipse-jdt-ls for java language.

Even nvim-lsconfig is faster and smoother, I stick to this plugin for vim. Really hope see that vim9 will have a performance boost, and the same for this plugin.

[sparkcanon]

Please try https://github.com/prabirshrestha/vim-lsp/tree/completion-perf branch. I have made some perf improvement primarily related to autocomplete. For best perf you need vim with lua that has exists('*matchfuzzypos')

Apologies for the late response I had a rather busy week. I tried completion-perf and I found that I no longer get a slight delay during completions. I tried with mostly typescript and javascript files. Thank you for your work.

[sparkcanon]

I'm not sure what you mean by non-responsiveness, is this vim freezing or that vim is responsive and just takes time to show the signature. Signature help doesn't seem to have cutomizable timers. Can you try changing timer_start(500 to a value you would like too. Feel free to send a PR to customize this.

I shall give this a try and report back once I have found a good value for the timer.

I have been using Typescript codebase for some of the perf profiling but is only 5k lines of code. If you have examples of open source projects that have 15k lines of code or higher let me know and can use it to profile.

Perhaps we can use apollo client for this purpose? It has nearly 15k loc.
I shall try to find one.

[prabirshrestha]

@sparkcanon

completion-perf branch is now in master. Please give it a try. I had to remove some features to make it fast but should not be noticable for most of the folks. Main one being removing support for preview window as it requires computing documentation for all items. If you are using popup for documentation there should be no issue since the documentation is computed on the fly as you select items. This avoid huge computation. I have also got rid of other heavy computations such as trim and substitute and made the logic to show ~ simpler.

I was trying to find examples that have 15k in a single file. I do have lot of other bigger projects than this I can try but files aren't as big. Wanted to make sure I'm profiling the right ones and trying to see if it is diff, json that is causing perf instead of autocomplete.

There are still lot more perf related to completion that is possible. I just need free time to implement more of these :)

[sparkcanon]

completion-perf branch is now in master. Please give it a try.

Already using it, thank you!

I was trying to find examples that have 15k in a single file. I do have lot of other bigger projects than this I can try but files aren't as big. Wanted to make sure I'm profiling the right ones and trying to see if it is diff, json that is causing perf instead of autocomplete.

I haven't come across any javascript open source projects so far in the wild, unfortunately. I shall keep my eyes peeled.

There are still lot more perf related to completion that is possible. I just need free time to implement more of these :)

looking forward to it!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[georgeharker]

everything works beautifully (and fast) for me - unless I have g:lsp_enable_fold on in which case completion is very slow, lags on both starting completion and completing.

i'm using vim-lsp-settings with pylsp and i've done a fair bit of testing to narrow it down to that specific setting.

I do not have semantic highlighting enabled and other performance settings are as per docs. vim-lap is using lua.

Thanks for all your hard work. Just curious there any known issues with folding and / or similar things that can be done for that?

George

Edit: FWIW setting up fast fold resolved this for me.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.