Snippets Causing Huge Delay

[SethGower]

Not sure if this is a great title, so I can change it if necessary. I have been having an issue recently, where I have huge delays when my editor (Neovim) goes to complete something. I boiled it down to when the client says that snippets are supported or not (with the capabilities.textDocument.completion.completionItem.snippetSupport flag). I have further boiled it down to when there is a library in the scope that has a lot of possible entities that can be completed. The reason I am hitting this is because of Xilinx's unisim library, which houses the VHDL component declarations for all of their primitive elements. In this file, there are a whopping 425 components defined. When this is included in the project and included in the unit I am working in with library/use calls, I am experiencing 1-5s of delay when completing an item. During this delay, my entire editor freezes.

I am not sure if this is an issue specifically with vhdl_ls, Neovim's nvim-lspconfig (doubt), or the completion engine I am using, nvim-cmp-lsp (potentially? relevant reddit post, but that says that it is probably the LSP server).

Obviously there are a couple ways to work around this issue

• Disable snippets for this LSP (as I have done for now). This isn't ideal, since the snippets are really helpful
• Remove the unisim library from the project. This is also not ideal, since then it can't lint these instantiations, and gives a ton of errors if you use them.

Since neither of these are great, would it be possible to add another work around by adding the ability to disable snippets on a library by library basis? Something like

[libraries]
unisim.files = [
    '$XILINX_VIVADO/data/vhdl/src/unisims/unisim_VCOMP.vhd',
    '$XILINX_VIVADO/data/vhdl/src/unisims/primitive/*.vhd*',
]
unisim.is_third_party = true
unisim.disable_snippets = true

This might also be a symptom of another, deeper issue that can be solved. Since it would be nice to have the instantiation snippets for the primitives that are defined here (although IMO not necessary. Most of the time I am not using these primitives, and if I am, I will probably copy the template out of Xilinx's docs).

[Schottkyc137]

I just tried out the server with neovim and I also experience the lags. I will investigate further, but I don't see the same behaviour for VSCode, so this is potentially an issue of sorts with neovim.

[Anselmo95]

Maybe it's not related but I noticed the lag too and after a bit of digging I found out that on my pc vhdl_ls is not killed after closing neovim.

So after two weeks I had around 200 instances of vhdl_ls running and killing all of them mostly solved the lag.

[SethGower]

Maybe it's not related but I noticed the lag too and after a bit of digging I found out that on my pc vhdl_ls is not killed after closing neovim.

So after two weeks I had around 200 instances of vhdl_ls running and killing all of them mostly solved the lag.

I have also noticed this before. Not sure if it's related. I just killed all orphaned processes, then tested, still getting the same lag.

[SethGower]

I just tried out the server with neovim and I also experience the lags. I will investigate further, but I don't see the same behaviour for VSCode, so this is potentially an issue of sorts with neovim.

yeah, I was talking with a coworker who uses VSCode, and he doesn't have the issue. I assumed this was a neovim specific problem, since VSCode is the "default" most people use. So if it were affecting that as well, this probably would have come up way earlier.

I tried a different completion engine, coq_nvim, and that doesn't seem to have the same lag. So I am going to create a corresponding issue on nvim-cmp.

[SethGower]

I love that github showed the reference to my dotfiles repo commits....