Performance / Lag issues

[kyazdani42]

Hello, please don't make yet another issue or comment an existing issue regarding huge lag in nvim-tree.

Please see performance-issues in the README.

If your editor start to lag when using nvim-tree, it might be because of several things:

• you are using fish as an editor shell (which might be fixed in the future), try set shell=/bin/bash in your vim config.
• you are running in a git directory with lots of changes:
  • try running git status --porcelain=v1 --ignored=matching -u and see if it hangs for a while. If it does, try disabling the git integration all by itself:

-- this is lua code (in `init.lua`)
require'nvim-tree'.setup {
  git = {
    enable = false
  }
}

I have to disclaim that the git status handling will never be fast on huge directories (trying to run the command above with GIT_DIR set did take a few 16seconds on my machine). The data returned is really heavy and slows down the editor just by itself (loaded 40 to 80mb just of git status text, which can represent 300 or more MB of data in ram which slows down the nvim process).

Usually, it works fine on most repositories, but will probably slow down sometimes.

Alternatively, each git process is now discarded after a configured timeout which is 400ms by default. This is configurable in

require'nvim-tree'.setup {
  git = {
    enable = true,
    timeout = 400 -- (in ms)
  }
}

Thank you all for reading this.

[tomspeak]

I've followed all the steps to improve performance, but am still having a ~10 second delay when opening nvim-tree.

Are there any other things I can do to improve performance?

17949 directories, 187762 files

Most of which is node_modules noise.

[kyazdani42]

because you source your node_modules into version control ? I think you should start using #682 or disable the git management alltogether at this point. If the tree gets slower because of git, that means git is slow itself.

[tomspeak]

sorry that was super vague —

I am not using the fish shell. I am working inside of a subdirectory of an extremely large monorepo (to the extent we have to use a modified git client to handle it). We do not check in node_modules into version control. Because of the size of the repo, I can never use any kind of git integration.

I have applied this to my config:

  git = {
    enable = false,
    ignore = false,
    timeout = 1
  }

But am still seeing a 10 second delay in opening, so was wondering if there's some other optimisation that I've missed?

[kyazdani42]

if you use the master branch, you need to set the comment above

vim.g.nvim_tree_show_icons = {
	git = 0,
  folders = 1 -- or 0,
  files = 1 -- or 0,
  folder_arrows = 1 -- or 0
}
vim.g.nvim_tree_gitignore = 0
vim.g.nvim_tree_git_hl = 0

[tomspeak]

@kyazdani42 works perfectly, it's lightning fast now, thank you!

One quick note: the commas are commented out so cause a syntax error

vim.g.nvim_tree_show_icons = {
  git = 0,
  folders = 1, -- or 0,
  files = 1, -- or 0,
  folder_arrows = 1 -- or 0
}
vim.g.nvim_tree_gitignore = 0
vim.g.nvim_tree_git_hl = 0

[piyoki]

@kyazdani42 works perfectly, it's lightning fast now, thank you!

One quick note: the commas are commented out so cause a syntax error

vim.g.nvim_tree_show_icons = {
  git = 0,
  folders = 1, -- or 0,
  files = 1, -- or 0,
  folder_arrows = 1 -- or 0
}
vim.g.nvim_tree_gitignore = 0
vim.g.nvim_tree_git_hl = 0

After adding the configs above, it does solve the lagging issue.

[pedropmedina]

I'm experiencing this issue following the latest update. The lag seems more prominent when writing the buffer.

Here's my setup:

local tree_cb = require("nvim-tree.config").nvim_tree_callback

vim.g.nvim_tree_indent_markers = 1
vim.g.nvim_tree_hide_dotfiles = 0
vim.g.nvim_tree_git_hl = 0
vim.g.nvim_tree_gitignore = 0
vim.g.nvim_tree_root_folder_modifier = ":t"
vim.g.nvim_tree_ignore = { ".git", "node_modules", ".cache" }
vim.g.nvim_tree_show_icons = { git = 0, files = 1, folders = 1 }
vim.g.nvim_tree_icons = {
	default = "",
	symlink = "",
	git = { unstaged = "•", staged = "•", unmerged = "≠", renamed = "•", untracked = "•" },
	folder = { default = "+", open = "-", empty = "+", empty_open = "-" },
	lsp = { hint = "•", info = "•", warning = "•", error = "•" },
}

require("nvim-tree").setup({
	disable_netrw = true,
	hijack_netrw = true,
	open_on_setup = false,
	ignore_ft_on_setup = {},
	auto_close = false,
	open_on_tab = false,
	update_to_buf_dir = {
		enable = true,
		auto_open = true,
	},
	hijack_cursor = false,
	update_cwd = true,
	update_focused_file = {
		enable = true,
		update_cwd = false,
		ignore_list = { ".git", "node_modules", ".cache" },
	},
	system_open = {
		cmd = nil,
		args = {},
	},
	filters = {
		dotfiles = false,
		custom = {},
	},
	git = {
		enable = false,
	},
	view = {
		width = 35,
		height = 35,
		side = "left",
		auto_resize = false,
		mappings = {
			custom_only = false,
			list = {
				{ key = "l", cb = tree_cb("edit") },
				{ key = "<C-s>", cb = tree_cb("split") },
				{ key = "h", cb = tree_cb("close_node") },
				{ key = "!", cb = tree_cb("toggle_ignored") },
				{ key = ".", cb = tree_cb("toggle_dotfiles") },
			},
		},
	},
	trash = {
		cmd = "trash",
		require_confirm = true,
	},
})

[kyazdani42]

@pedropmedina got not lag whatsoever with your config on my machine. update your plugins and fix your config, there are some deprecated variables. are you using fish ? if so set shell=/bin/bash could help.

[pedropmedina]

Hi @kyazdani42, I'm using zsh. I also tried using the default setup, just require('nvim-tree').setup({}), but that did not fix the lag either.

Here's my nvim version:

NVIM v0.5.1
Build type: Release
LuaJIT 2.1.0-beta3

I also tried disabling all plugins, but that did not improve the performance. The issue takes place when I enable nvim-tree. Expanding tree nodes, creating and deleting new files takes ~ 1.5 seconds to 2 seconds. Also writing the current buffer takes a while to finish. No sure what it could be as I haven't changed anything since the last update.

Also, which are the deprecated variables you found in my config?

[perkfly]

Why would fish cause this issue? That seems weird. If I set shell as bash in my config, then the terminal inside nvim would also be bash, that would be a dealbreaker for me.

[jdhao]

Nvim-tree is slow to open for a non-git directory with 100000 files

I create 100000 files under a directory ~/projects/trail_error:

for i in {0..100000}
do
    echo ${i}
    touch  "content/file-${i}.txt"
done

When I open nvim (nvim -u minimal.vim) and run :NvimTreeToggle, move the cursor to content directory and press Enter, I experience lag of 5-6 seconds before I see the file under this directory. This issue is not related to git, since neither the root directory nor this directory is a git repo.

My minimal config:

set runtimepath+=/Users/jdhao/.local/share/nvim/site/pack/packer/opt/nvim-tree.lua

lua << EOF
  require'nvim-tree'.setup({})
EOF

Can the file loading be made asynchronous like what chadtree does?

[kyazdani42]

@yifeikong well i'm not sure why, but many fish users have issues with the tree, and i've never been able to reproduce, but setting the shell to bash made the whole thing fast again. So this must be fish related, if someone could've pinpoint the issue i might have fixed it but no one has yet. I use zsh myself and never had an issue of the tree taking more than a few hundred ms to load on big folders.

@jdhao even a 50K folder will be slow for a lot of things. I ran exa (ls multithreaded), takes >1sec, git status takes 0.5 sec to output, even the shell is slow :smile: The tree has to do some extra stuff to associate the git statuses to the nodes, and there is no way to speed up a simple loop like this unfortunately. Try to iterate a 100K times in lua, it will be slow anyway.

I believe asynchronous file loading would just complexify the whole codebase, if i don't use plenary's async library (and i'd like to avoid having dependencies for now). These are very edge case performance issues that might be fixed by optimizing the code and cleaning it up, not deferring the operations later on the thread. If you have a 100K async operations going to land at any time, it will actually use the thread when doing the computations and will slow the whole thing again, so this does not fix the issue.

Chadtree is written in python and the whole thing is running on a separate detached process, which does not block neovim. Using lua you get better feedback but when it gets huge tables, it will slow down within the neovim process.

I hope i answered this correctly :) maybe some performance testing would be nice in order to avoid regressions, once the codebase is cleaned up.

[gegoune]

Wasn't sure if I should open new issue for that or use this pinned one. Didn't feel like I have enough information to warrant new issue. Anyways, since recent refactors (did not check exactly which commit) nvim-tree's startup time has increased around 2-3 times.

       startup: 241.9
event                  time percent plot
nvim-tree.lua         29.92   12.37 ██████████████████████████
VimEnter autocommand  28.33   11.71 ████████████████████████▋

Prior to recent updates it was around low 10's if I remember correctly.

I have not more details about it at the moment, just wanted to bring it to your attention. I do use impatient.nvim, so uncached times would be way higher.

(loved recent activity, plugin works very well now, thank you so much for all your hard work on it!)

[kyazdani42]

I do not defer the on_enter call during setup anymore, that's why it takes a bit longer. But it actually causes #942 and #944 so i might just fix this again.

[kyazdani42]

@gegoune i've rescheduled the on_enter because it was conflicting a lot. I also deferred autocmd setup after the on_enter to avoid clashing. Does this fix the performance regression you observed ?

[gegoune]

@kyazdani42, it has, thanks!

nvim-tree.lua         11.44    5.20 ████████████▎

[notjedi]

@gegoune sorry to bother but what program are you using to profile? mind sharing? ty

[gegoune]

@gegoune sorry to bother but what program are you using to profile? mind sharing? ty

Not a bother at all. It was generated by dstein64/vim-startuptime. Have fun! :)

[notjedi]

@gegoune thank you so much

[apmyplol]

In my case the huge lag/crash only happens when I run neovim in a directory, i.e. nvim .. The tree-view on the side works absolutely fine if istead of running nvim . I dot nvim bla.md and then open the sideview.

Disabling git integration solves the issue as well, but looks like the problem is not really the git integration but the tree view which is opened when running neovim in a directory. Maybe this information will be of help when trying to fix this issue, thanks as always! 🙆

[xyos]

I'm having the same issue using fish, setting my shell to bash solved it

[bva99]

Interesting. If I never open nvim-tree, saves (:w/:wa) aren't slow. But if I open it once, saves become slow. Using cmd.exe in Windows (yes, I know...). I've noticed a similar behaviour as apmyplol.

[alex-courtis]

Interesting. If I never open nvim-tree, saves (:w/:wa) aren't slow. But if I open it once, saves become slow. Using cmd.exe in Windows (yes, I know...). I've noticed a similar behaviour as apmyplol.

You are not the first to experience such issues on windows. Please enable performance logging and share your experiences.

[kyazdani42]

@bva99 you could set auto_reload_on_write = false and manually run NvimTreeRefresh when needed.

[boltlessengineer]

The lag in fish shell may occur because of config.fish file. Not nvim-tree's problem. I had the same problem, but I was able to find the cause in fish-shell#7004.

fish always loads its config, even if it isn't interactive.

So I could solve this problem by wrapping my config.fish file like this.

if status is-interactive
  # {{ All my old `config.fish` contents }}
end

Hope this could help some fish&neovim users

[alex-courtis]

So I could solve this problem by wrapping my config.fish file like this.

Thanks for the tip @boltlessengineer. Added to README

[0x00002a]

Just want to report I am using zsh and was getting timeouts even when setting timeout = 1000, setting it to bash also fixed it for me. This only started being an issue the last few days, I'm not 100% sure if its due to a nvim tree update or something else on my system though

[alex-courtis]

Just want to report I am using zsh and was getting timeouts even when setting timeout = 1000, setting it to bash also fixed it for me.

Please enable profiling. Seeing performance under bash and zsh will be useful.

[notjedi]

@kyazdani42 facing issues when saving a file. saving the file takes a minimum of one second. this only happens when i have opened nvim-tree at least once before. do you have any idea what is causing this issue?

EDIT: this only happens in that specific directory. opening and closing nvim-tree is also slow (500-1000 ms). it is a git repo, does it have to do anything with that? but it's really a small git repo with not even 20 commits and SLOC is also small

[kyazdani42]

did you follow the description in the comment ? Does the git status command take time ?

[notjedi]

nevermind, it's because i had a folder with 163000 files. totally forgot that i moved it inside the git repo folder. is there any workaround to exclude that folder? i better go read the docs. ty

[0x00002a]

Just want to report I am using zsh and was getting timeouts even when setting timeout = 1000, setting it to bash also fixed it for me.

Please enable profiling. Seeing performance under bash and zsh will be useful.

@alex-courtis apologies for the delay. I've enabled logging and captured logs both with the 25ms timeout that I use normally (which doesn't timeout with /bin/bash as the shell, at least on refreshes) and with a 60000ms timeout (which still got hit). Unfortunately theres not much there but I can at least confirm that there is something incredibly weird going on with my setup given a 1 minute timeout was still hit when it works within 25ms in bash. Also I noticed there was some noise from zsh startup so I also tried with return at the start of my .zshrc which should emulate a clean install.

Also also I ran git --no-optional-locks status --porcelain=v1 --ignored=matching -u with time in both zsh and bash, the numbers are pretty much the same for both shells and correspond to the numbers in the perf log from nvim-tree for bash, inc the part where it gets faster on later runs

log with 25ms timeout log with 1 minute timeout "clean" zshrc bash log with multiple refreshes (100ms timeout)

[alex-courtis]

log with 25ms timeout [2022-07-17 18:19:50] [profile] START git job discover_other_daemon: 1/home/ash/sources/nvim-tree.lua nil

That shows an incorrect cwd which will never work.

Bash shows: [2022-07-17 18:50:16] [profile] START git job /home/ash/sources/nvim-tree.lua nil

That is normal, with the correct cwd.

Do you run gnome keyring? A quick intersearch revealed https://bbs.archlinux.org/viewtopic.php?id=276606

[0x00002a]

Do you run gnome keyring? A quick intersearch revealed https://bbs.archlinux.org/viewtopic.php?id=276606

yeah I run gnome-keyring, I wondered if it was the issue which is why I also tried it with a "clean" zshrc which didn't start it. Thanks for the link though I've been meaning to get round to fixing that xD

[0x00002a]

OK yeah you were spot on with gnome-keyring, just swapped to using a service file for it and removed it from my zshenv (thats possibly why it wasn't working when I disabled my zshrc), it now works fine.

[archiif]

I'm having serious performance issues, but only when navigating up to a large directory. nvim locks up and its memory usage gradually grows larger and larger (>1GB), forcing me to crash it.

But if I start nvim in that large directory and launch nvim-tree, it loads them just fine.

I don't think it has any thing to do with git, because it wasn't a git directory.

Oddly, I can't reproduce it 100% of the time (it's probably happens closer to 80% of the time), but it always happens when I navigate up to the large directory with -.

The directory isn't even that large, only containing around ~200 directories and a few files. Any clues on what is causing this?

[kyazdani42]

could you enable the logging and see if there is something unexpected happening first ? Without more information it would be quite hard to help you on that matter :)

[archiif]

I forced nvim to quit after it ate >1GB of RAM and these are the final lines of the log:

[2022-07-31 21:07:15] [profile] START change dir C:\Users\foo\AppData\Local
[2022-07-31 21:07:16] [profile] START draw
[2022-07-31 21:07:16] [profile] END   draw  3ms
[2022-07-31 21:07:16] [profile] END   change dir C:\Users\foo\AppData\Local  259ms
[2022-07-31 21:07:17] [profile] START draw
[2022-07-31 21:07:17] [profile] END   draw  3ms
...
[2022-07-31 21:07:38] [profile] START draw
[2022-07-31 21:07:38] [profile] END   draw  3ms
[2022-07-31 21:07:38] [profile] START change dir C:\Users\foo\AppData\Local\Everything
[2022-07-31 21:07:38] [profile] START draw
[2022-07-31 21:07:38] [profile] END   draw  1ms
[2022-07-31 21:07:38] [profile] END   change dir C:\Users\foo\AppData\Local\Everything  29ms
[2022-07-31 21:07:40] [profile] START change dir C:\Users\foo\AppData\Local
[2022-07-31 21:07:40] [profile] START draw
[2022-07-31 21:07:40] [profile] END   draw  2ms
[2022-07-31 21:07:40] [profile] END   change dir C:\Users\foo\AppData\Local  205ms
[2022-07-31 21:07:40] [profile] START find file C:\Users\foo\AppData\Local\Everything\Everything.db

It seems that it locks up when it tries to refind the previously selected file after you go up a directory.

[alex-courtis]

Thanks for reporting; it's very useful to have data from windows users. I assume Local is the large directory, which I believe is a special windows directory. ~200ms doesn't seem too long, though.

Idea: exclude these special directiories as per https://github.com/kyazdani42/nvim-tree.lua/commit/ac906640011df013ca3dd19b6dc71a4fec67cf85

@archiif to track this isse properly, please raise a new bug. Having information around version, config etc. is necessary, as we have just cut over to using file system events to enumerate files.

When you raise, please collect another log with nvim-tree.log.types.watcher set.

[kyazdani42]

The issue isn't with the 200ms change dir, it's the find_file call that seems to hang. It's possible that if the find file command doesn't find a file in a large folder, it will probably expand all folders, and if there is a link of some kind, it might recurse for quite a while. As alex's said, please open an issue :)

[archiif]

I managed to come up with a set of reproducible steps for the bug: https://github.com/kyazdani42/nvim-tree.lua/issues/1480

As @kyazdani42 suggested, looping symlinks were the cause.

[alex-courtis]

As @kyazdani42 suggested, looping symlinks were the cause.

Oh wow... good find.