Archived: Performance / Lag issues

[kyazdani42]

Update 20221217

If you experience performance issues please look at wiki : Troubleshooting and raise a new bug report if you still experience issues.

20221108

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.

[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?

[perklet]

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 😄
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 ████████████▎

[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 ac90664

@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: #1480

As @kyazdani42 suggested, looping symlinks were the cause.

[alex-courtis]

As @kyazdani42 suggested, looping symlinks were the cause.

Oh wow... good find.

[alex-courtis]

Performance is stable and problems documented in the README.

Please raise a bug report if you encounter any performance issues.

[Lengdrich]

I have a same problem when I use nvim-tree. When I entered neovim and used the nvim-tree at the first time, this problem will occurred. The first time of using nvim-tree will take 20s.
my environment is wsl2 . At the beginning, I used fish shell , when I see the issue, I changed to bash, but the problem still occurred;

this is my config of nvim-tree:

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

And I also set shell = /bin/bash in my vim config.

This is a demo video:

Rec.0001.mp4

[alex-courtis]

I have a same problem when I use nvim-tree. When I entered neovim and used the nvim-tree at the first time, this problem will occurred. The first time of using nvim-tree will take 20s.

We've seen this before: 20s freeze after first git status on WSL: #1719

Some fixes have been made in that area however some problems still remain.

@codeBruyne please:

• ensure latest nvim-tree, git and vim
• enable log collection as per https://github.com/nvim-tree/nvim-tree.lua/wiki/Troubleshooting#performance-issues
• test following cases:
  • git enabled, watchers disabled
  • git disabled, watchers enabled
  • git enabled, watchers enabled
• reply with your findings at new watcher event on .git freezes neovim #1719 (reply in thread)

Unfortunately no nvim-tree developers have access to or expertise with windows: diagnosis and fix will take an extended time.

[pedro2d10]

Hello all!
It seems that I have the same issue on wsl2. I disable git and filesystem_watcher in my nvim-tree conf. But every time I open nvim-tree, i have a 100s delay before nvim-tree start to draw the directories.
It seems to be stuck at [watcher] purge_watchers even if the watcher is not enable.

[alex-courtis]

It seems to be stuck at [watcher] purge_watchers even if the watcher is not enable.

That one is just a regular startup message and does nothing unless the user is calling setup multiple times. Removed 899ed45

[alex-courtis]

I've added some more profiling to hopefully narrow down on the issue. Please pull latest 95ed588 and enable profiling

[pedro2d10]

I've added some more profiling to hopefully narrow down on the issue. Please pull latest 95ed588 and enable profiling

Here the following logs:
`[2022-12-16 08:57:24] [profile] START core init /home/pierre/.config/nvim

[2022-12-16 08:57:24] [watcher] Watcher:new '/home/pierre/.config/nvim' nil

[2022-12-16 08:57:24] [watcher] Event:new '/home/pierre/.config/nvim'

[2022-12-16 08:57:24] [watcher] Event:start '/home/pierre/.config/nvim'

[2022-12-16 08:57:24] [profile] START explore init /home/pierre/.config/nvim

[2022-12-16 08:58:24] [watcher] Watcher:new '/home/pierre/.config/nvim/lua' nil

[2022-12-16 08:58:24] [watcher] Event:new '/home/pierre/.config/nvim/lua'

[2022-12-16 08:58:24] [watcher] Event:start '/home/pierre/.config/nvim/lua'

[2022-12-16 08:58:24] [watcher] Watcher:new '/home/pierre/.config/nvim/plugin' nil

[2022-12-16 08:58:24] [watcher] Event:new '/home/pierre/.config/nvim/plugin'

[2022-12-16 08:58:24] [watcher] Event:start '/home/pierre/.config/nvim/plugin'

[2022-12-16 08:58:24] [profile] END explore init /home/pierre/.config/nvim 60178ms

[2022-12-16 08:58:24] [profile] END core init /home/pierre/.config/nvim 60179ms

[2022-12-16 08:58:24] [profile] START view open

[2022-12-16 08:58:24] [profile] END view open 9ms

[2022-12-16 08:58:24] [profile] START draw

[2022-12-16 08:58:24] [profile] END draw 0ms
`

As you can see, there 60s between profiling start and watcher.

I hope this will help

[alex-courtis]

@pedro2d10 continuing in new bug #1831

[alex-courtis]

If you experience performance issues please look at wiki : Troubleshooting and raise a new bug report if you still experience issues.