Slows neovim on startup

[carlitux]

Package manager: packer.nvim

Using as a start plugin slows the first rendering, adding as a lazy plugin using as opt plugin do not render anything

.

[kyazdani42]

hello,
I do not know what lazy rendering is (i basically just add my plugin to my runtimepath manually so...), i've never had slow startups especially compared to other trees, this tree is MUCH faster and doesn't make the whole ide run slowly. I tested on a 40K file directory and well, it just works under 1sec, which is like 10 times faster than other tree implementations (maybe not all of them but feel free to test them out :) ). I also use it everyday for work.
So please describe your issue in a better way

[carlitux]

@kyazdani42 yes, it is faster but startup is slow as you can see in log files, with the plugin it is 3x slower than without it.

vim-without-lua-tree.log
vim-with-lua-tree.log

Sorry if I explained wrong but I didn't talk about lazy rendering, I mean that when package (:help packages) feature is used where nvim-tree.lua is put in opt file and running this commands:

packadd nvim-tree.lua
LuaTreeOpen

Do not work, as the image I sent before.

[akinsho]

I think some of this might relate to how packages handles lua plugins, I'm no expert though. I profile my vim startup a fair bit and lua tree is never anywhere near the top 🤷.

[kyazdani42]

I'm not using this feature, and i don't have much time lately trying to fix other people issues :/
If you could find a way to fix this, open a PR, i would be happy to accept it if it makes other people happy :)

[comfortablynick]

I also attempt to lazy load as many plugins as possible using the opt directory in &packpath. This plugin initially worked doing that, but then stopped. I think I figured out why: it now uses the VimEnter event to initialize the plugin..

https://github.com/kyazdani42/nvim-tree.lua/blob/640d147d706aa33f096f5585176fd3c76303377b/plugin/tree.vim#L17

Before a refactor about four months ago, it looks like that was only used if g:lua_tree_auto_open == 1

To test this, I was able to do something like this to lazy load, which seems to work fine:

function! s:load_luatree() abort
  packadd nvim-tree.lua
  lua require"tree".on_enter()
  LuaTreeToggle
endfunction

command! -nargs=0 LuaTreeToggle call s:load_luatree()

That being said, I don't notice a large hit on my :startuptime with this plugin. It's just not something I use every time, so I tend to prefer a lazy load.

[kyazdani42]

i'll see what i can do. Thanks for pointing that out

[kyazdani42]

I ran the on_enter function when loading the package instead of doing it on VimEnter. If it fixes your issue, could you point that out to me ? thanks

[comfortablynick]

Yes, it seems to work for me. Thanks!

[kyazdani42]

still has an issue i've found disturbing, if running on plugin load and not lazy loading it, it will start the tree on man ... if your manpager is nvim, or other situations you don't want the tree to open.
I might be fixing this in the rewrite though.
EDIT: i fixed this in master but this is a little weird at startup

[comfortablynick]

I tried this again, and it looks like the defer_fn added to the on_enter function breaks lazy loading.

https://github.com/kyazdani42/nvim-tree.lua/blob/ebf6f2a21ab55f4a157fffa8a1b3ae9c414c1022/lua/tree.lua#L199

For example, if I do:

packadd nvim-tree.lua
LuaTreeToggle

I get a blank buffer. I still need to add lua require'tree'.on_enter() in between those two commands.

EDIT: If I remove the defer_fn in the plugin, it works as expected.

[kyazdani42]

yeah well the current architecture of the repo doesn't really allow for lazy loading anyway... maybe removing on_enter from the config should work.

[kyazdani42]

closing this since the setup now allows to do this