-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Severe performance degradation #44
Comments
After some investigation, i think the debug config option, is what nukes the performance so hard, but given the fact that i have pretty much no linters or formatters installed, i wonder why would it be so impactful, even with debug turned on, does it do something else besides logging the requests ? It seems that on average the debug would log in the file up to 1KB of data per request, most notable offenders are didChange and the completion commands/requests from the lsp spec. If nothing else, it would be good to add explicit warning that null ls runs on the main thread and and add some docs on the debug option, that it performs io operations and this can be very costly due to the amount of data being logged |
FAQ
Issues
Neovim Version
0.9.4
Dev Version?
Operating System
MacOs
Minimal Config
Steps to Reproduce
This is something that i have observed recently, i am mostly using null-ls to attach custom code actions through the generator api. And have just two formatters installed (active at most, stylua and clang format), besides a couple of formatters. However, recently on my trashy m1 at work i started noticing severe performance hits with two very hot paths - didChange and autocompletion. Whenever the internal neovim lsp client would trigger the text change notify event, to notify the server of the changes in the buffer, and whenever the autocompletion engine (nvim-cmp in my case) would request candidates i noticed a severe lag while having null-ls enabled. Went in and disabled it in my config, and after that the issue completely vanished.
The issue is very reproducible when we do changes in the buffer with a macro, say pasting over a word is what i mostly experimented with, over a few lines (dozen) in a buffer that is no bigger than 200 lines, the macro would be extremely laggy and slow, as far as completion goes, the moment you go into insert mode and start typing there is a significant lag / delay once i reach the minimal keyword count i have configured for nvim-cmp (which is 3 at the moment).
I tried disabling the primary language servers i tested with (lua and jdtls) and the issue persisted, only when i killed null-ls would i actually see sane performance, no stuttering, etc
Something to note, i increased the debounce which would help will avoiding the didChange spam , to something like 2seconds, and that fixed the issue while editing in normal mode, but nvim-cmp would still chug and stutter.
Reproducibility Check
minimal_init.lua
template and that my issue is reproducible by runningnvim --clean -u minimal_init.lua
and following the steps above.Expected Behavior
No perceived lag, especially when there are no configured formatters or linters at all.
Actual Behavior
Severe drop in performance during the two most hot paths, which modifying the buffer and while auto completing.
Debug Log
None
Help
Yes, but I don't know how to start. I would need guidance
Implementation Help
No response
Requirements
The text was updated successfully, but these errors were encountered: