clarification about lazy loading on keys

[gennaro-tedesco]

This is not really a bug report, rather a request for clarification about loading start-up times.

environment

NVIM v0.10.0-dev-1496+g4c8fdc018-Homebrew
Build type: Release
LuaJIT 2.1.1699180677

macOS 13.6.1 Ventura

I have noticed that lately vim-matchup causes neovim to start very slowly, I am not sure exactly if due to latest commits on treesitter (vim-matchup using treesitter integration) or on this repository itself: I have tried to "binary debug" the commit history unsuccesfully. What I see is that vim-matchup itself requires a start-up time of around ~300ms, and I wonder if some sort of lazy loading can be achieved to delay its invocation till its usage: currently I am using lazy.nvim as package manager and my vim-matchup configuration is the below:

...
{
"andymass/vim-matchup",
event = "BufReadPost",
init = function()
    vim.g.matchup_matchparen_offscreen = { method = "popup" }
    vim.g.matchup_surround_enabled = 1
end,
}

usually lazy.nvim supports lazy loading on key presses, thus I tried to lazy load on keys = {"%"} (for the sake of the example, assuming we only want to use the % motion), however it seems that doing so never loads the plugin at all (the startup times are vastly reduced, but the plugin does not load on key invocation).

Since this is written in VimScript I was wondering if there is still some sort of autoload mechanism á la vim that makes loading on keys ineffective. What is your opinion about this, have you observed it yourself too by any chance and would you recommend some other types of lazy loading instead?

P. S. I should add that disabling the plugin does reduce the start-up time greatly.

[andymass]

match-up is already using lazy loading, one problem is that it really does need to be loaded at buffer load since highlighting is a core feature. If you start it on % press, you'd miss the highlighting.

Can you provide any startup time logs so I can see where the improvements might be?

[gennaro-tedesco]

Sure, would you like me to run nvim --startuptime tmp.txt and attach the file or anything else (also, do you need part of the file in particular or the whole lot)?

[andymass]

Yeah, I can work with the whole startuptime file, if you are able to share that. Ideally it would show the 300 ms is coming from to help me debug.

For comparison the entire match-up load takes under 5ms on my computer

[gennaro-tedesco]

Please find attached the startup logs

tmp.txt

P. S. I am using lazy.nvim as package manager and on start-up I see the below:

which seems to be closer to the actual time I feel for start-up to take.

P. P. S. I have now accidentally noticed (by using another computer where I don't run nightly) that such problem doesn't exist with nvim --version 0.9, it is instead accentuated on nightly where I have observed treesitter to take a longer startup time than expected, en passant. Hence this may be due to possible treesitter dependencies within the plugin?

[andymass]

problem doesn't exist with nvim --version 0.9

Might explain why it works on my side

BTW as another sanity check, what happens when you don't lazy load and instead load using normal methods,; vim-matchup has an autoload system already, maybe lazy.nvim is messing with that?

[gennaro-tedesco]

what happens when you don't lazy load and instead load using normal methods

The above numbers are obtained without any lazy loading, even removing the event BufReadPost (which after all doesn't change much anyway). I am led to think that this may in truth due to treesitter alone, especially given that there are no other issues of users noticing it throughout the history of this plugin (which means that the plugin itself is very good and does most if not anything right already :) )