1-5s Delay when snippets enabled for certain LSP

[SethGower]

FAQ

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

Announcement

• [X] I have checked Breaking change announcement.

Minimal reproducible full config

if has('vim_starting')
  set encoding=utf-8
endif
scriptencoding utf-8

if &compatible
  set nocompatible
endif

let s:plug_dir = expand('/tmp/plugged/vim-plug')
if !filereadable(s:plug_dir .. '/plug.vim')
  execute printf('!curl -fLo %s/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim', s:plug_dir)
end

execute 'set runtimepath+=' . s:plug_dir
call plug#begin(s:plug_dir)
Plug 'hrsh7th/nvim-cmp'
Plug 'hrsh7th/cmp-buffer'
Plug 'hrsh7th/cmp-nvim-lsp'
Plug 'hrsh7th/vim-vsnip'
Plug 'neovim/nvim-lspconfig'
call plug#end()
PlugInstall | quit

" Setup global configuration. More on configuration below.
lua << EOF
local cmp = require "cmp"
cmp.setup {
  snippet = {
    expand = function(args)
      vim.fn["vsnip#anonymous"](args.body)
    end,
  },

  mapping = {
    ['<CR>'] = cmp.mapping.confirm({ select = true })
  },

  sources = cmp.config.sources({
    { name = "nvim_lsp" },
    { name = "buffer" },
  }),
}
EOF

lua << EOF
local capabilities = require('cmp_nvim_lsp').default_capabilities()

require'lspconfig'.vhdl_ls.setup {
  capabilities = capabilities,
}
EOF

Description

When I am using vhdl_ls, I can get into a case when there is a 1-5s delay when nvim is creating the completion menu. I have boiled the issue down to when I have snippets enabled, and am working in a project/file that uses a vendor library, which defines 425 "components". The vhdl_ls creates snippets for each one of these, and it seems that it might be sending too many snippets and overwhelming nvim-cmp?

Steps to reproduce

I have uploaded a gist with the file that seems to cause the issue. I am sure that this isn't the only one that could cause the issue, but since it is such a large one, it is the one causing it in this case.

Here is a VHDL file that shows the issue

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

library unisim;
    use unisim.vcomponents.all;

entity test1 is
    port (
        i_clk  : in    std_logic;
        i_rstn : in    std_logic;
        i_d    : in    std_logic;
        o_q    : out   std_logic;
        o_qn   : out   std_logic
    );
end entity test1;

architecture behav of test1 is

begin

    o_q_proc : process (i_clk) is
    begin

        if rising_edge(i_clk) then
            if (i_rstn = '0') then
                o_q <= '0';
            else
                o_q <= i_d;
            end if;
        end if;

    end process o_q_proc;

end architecture behav;

You can use the vhdl_ls.toml file to configure the LSP

[libraries]
defaultlib.files = [
    "./test1.vhd"
]

unisim.files = [
    './unisim_VCOMP.vhd',
]
unisim.is_third_party = true

If you edit the test1.vhd file, and then place your cursor on the empty line above end architecture behav; and start typing, you should notice the delay.

Expected behavior

There shouldn't be a significant delay (on the order of multiple seconds) when serving completions.

Actual behavior

When nvim is creating the completion dialog, it freezes the entire editor. Nothing can be done in this time. If it were simply a delay in when some of the candidates make it into the list, that would be less obtrusive, however it brings down the entire editor.

Additional context

I think that this is an issue in nvim-cmp (or maybe the LSP source, but still). I think this because I created an issue over on the vhdl_ls https://github.com/VHDL-LS/rust_hdl/issues/340 and this doesn't happen on VSCode. I also tried to get coq_nvim working to test if it is an issue there, and it isn't. I can perform the same steps, and it will show the results properly, and can also expand the snippets. However I prefer nvim-cmp vs coq_nvim, so I wanted to see if this can get investigated/fixed.

Please let me know if there is anything else that I can do to help, or anything else that I can provide in the meantime.

[xzbdmw]

Maybe you can try #1980

[SethGower]

I just checked their branch out, and am still getting the severe lag.