Snacks picker slow to open when many treesitter grammars are installed

[inorichi]

Hi, I'm asking a question here rather than opening an issue because maybe this is a very specific problem and isn't fixable.

I have neovim installed with home manager on NixOS, and I install all treesitter grammars with:

    plugins = with pkgs.vimPlugins; [
      nvim-treesitter.withAllGrammars
    ];

But this makes the picker slow to open (around ~300-500ms), and compared with FzfLua which opens instantly, I found it weird (with "open" I mean the time it takes to actually see the window, this is not about searching or interacting with the picker window). Even if the directory I invoke Snacks.picker.files() in has just one file, I can notice the delay.

If I comment out the snippet above, the snacks picker then opens instantly.

So I'm not sure whether this is a "just install less grammars" or something that can be actually fixed/improved.

[folke]

That's not a snacks issue. Snacks will load treesitter parsers for highlighting, for example for the files you are grepping.

To load a parser, Neovim will find the .so library in the runtime path.
I have no idea what that Nixos withAllGrammars does, but if that adds a separate directory (probably symlink) for each nvim-treesitter parser, then you will for sure get major slow-downs, and not only with the snacks picker.

[folke]

And are you 100% on the latest snacks.nvim commit?

[folke]

After opening the files picker once, when you then close it and open it again, is it then fast?

[inorichi]

For what picker do you see a slow-down when opening?

All of them, even colorschemes, registers or git_branches.

And are you 100% on the latest snacks.nvim commit?

Yes, I update regularly:
"snacks.nvim": { "branch": "main", "commit": "76311aba31182adcd85cc3381abca76b917668b7" }

I tried snacks picker around two weeks ago for the first time, and it's behaving like that since then

After opening the files picker once, when you then close it and open it again, is it then fast?

Nope, I can reproduce it 100% of the times

[folke]

colorschemes also uses the rtp.
I dont see how git_branches could be impacted by that though. No idea.

[inorichi]

After reducing them to ~50 parsers, it feels quite responsive now :)

Thanks!

[dkuettel]

I'm running into the same issue. I'm trying to understand which part is the problem. If I add only one grammar (lua, in my case) it's snappy fast to startup. But when I install all grammars, it has a very noticeable delay until the window is shown. It happens for both files() and buffers(), on a small repo, both lists are no more than 20 entries.

In both cases (few and many grammars) &rtp is quite short, about 15 entries. I guess it's not about the entry count in the &rtp variable, right? Just about the actual count of treesitter .so files that can be found thru it?

What part of pickers needs to scan all existing grammar files? Don't you only need it once you display the preview?

Edit: I see that in &rtp I have things like pack/*/start/* that do expand to many folders in case of many grammars. Do you think if I merge them into one folder it would be fast?

[dkuettel]

From my experiments, and looking at the snacks code, I think the problem is the use of vim.api.nvim_get_runtime_file("", true) in a few places, which is getting slow when you have many pack paths. When merging all grammars into just one pack, it is faster again, the number of actual grammar files is not a problem.

For people using nix, pkgs.vimPlugins.nvim-treesitter.withAllGrammars makes around 600 packs, as each grammar is a separate dependency. Merging is not very hard:

        compactTreesitterDependencies = pkgs.buildEnv {
          name = "compact-treesitter";
          paths = treesitterDependencies;
        };