Severe performance degradation

[Svetlozar Iliev]

FAQ

• I have checked the FAQ and it didn't resolve my problem.

Issues

• I have checked existing issues and there are no issues with the same problem.

Neovim Version

0.9.4

Dev Version?

• I am using a stable Neovim release version, or if I am using a dev version of Neovim I have confirmed that my issue is reproducible on a stable version.

Operating System

MacOs

Minimal Config

Default config, without any changes.

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

• I confirm that my minimal config is based on the minimal_init.lua template and that my issue is reproducible by running nvim --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

• I have read and followed the instructions above and understand that my issue will be closed if I did not provide the required information.

[Svetlozar Iliev]

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