Skip to content

Significant lag on start #453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
asmallcarrot opened this issue Jun 15, 2021 · 24 comments · Fixed by #499
Closed

Significant lag on start #453

asmallcarrot opened this issue Jun 15, 2021 · 24 comments · Fixed by #499

Comments

@asmallcarrot
Copy link

asmallcarrot commented Jun 15, 2021

Issue:

After a clean install of the latest version of nvim and no other plugins when I install nvim-tree.lua it takes ~1-2 seconds for me to be able to do any actions in a document. The document renders but I can not for example move my cursor.

System info:

OS: Artix w/ openrc
Terminal: ST
Nvim Version: v0.5.0-dev+1416-gec7b21918 (I tried the AUR version and built from source)

Start time log



times in msec
 clock   self+sourced   self:  sourced script
 clock   elapsed:              other lines

000.009  000.009: --- NVIM STARTING ---
000.322  000.313: locale set
000.683  000.361: inits 1
000.698  000.014: window checked
000.702  000.004: parsing arguments
000.801  000.099: expanding arguments
000.853  000.052: inits 2
001.437  000.584: init highlight
001.438  000.001: waiting for UI
002.015  000.577: done waiting for UI
002.033  000.019: initialized screen early for UI
005.706  003.600  003.600: sourcing /home/rice/.config/nvim/init.lua
005.711  000.078: sourcing vimrc file(s)
010.559  004.828  004.828: sourcing /usr/local/share/nvim/runtime/filetype.vim
010.700  000.023  000.023: sourcing /usr/local/share/nvim/runtime/ftplugin.vim
010.843  000.020  000.020: sourcing /usr/local/share/nvim/runtime/indent.vim
011.193  000.179  000.179: sourcing /usr/local/share/nvim/runtime/syntax/syncolor.vim
011.353  000.368  000.189: sourcing /usr/local/share/nvim/runtime/syntax/synload.vim
011.411  000.456  000.088: sourcing /usr/local/share/nvim/runtime/syntax/syntax.vim
011.776  000.210  000.210: sourcing /home/rice/.config/nvim/plugin/packer_compiled.vim
012.101  000.157  000.157: sourcing /usr/local/share/nvim/runtime/plugin/gzip.vim
012.117  000.006  000.006: sourcing /usr/local/share/nvim/runtime/plugin/health.vim
012.176  000.051  000.051: sourcing /usr/local/share/nvim/runtime/plugin/man.vim
012.477  000.143  000.143: sourcing /usr/local/share/nvim/runtime/pack/dist/opt/matchit/plugin/matchit.vim
012.534  000.349  000.206: sourcing /usr/local/share/nvim/runtime/plugin/matchit.vim
012.647  000.105  000.105: sourcing /usr/local/share/nvim/runtime/plugin/matchparen.vim
012.944  000.288  000.288: sourcing /usr/local/share/nvim/runtime/plugin/netrwPlugin.vim
013.062  000.007  000.007: sourcing /home/rice/.local/share/nvim/rplugin.vim
013.067  000.105  000.099: sourcing /usr/local/share/nvim/runtime/plugin/rplugin.vim
013.146  000.069  000.069: sourcing /usr/local/share/nvim/runtime/plugin/shada.vim
013.177  000.015  000.015: sourcing /usr/local/share/nvim/runtime/plugin/spellfile.vim
013.291  000.102  000.102: sourcing /usr/local/share/nvim/runtime/plugin/tarPlugin.vim
013.368  000.062  000.062: sourcing /usr/local/share/nvim/runtime/plugin/tohtml.vim
013.392  000.011  000.011: sourcing /usr/local/share/nvim/runtime/plugin/tutor.vim
013.540  000.137  000.137: sourcing /usr/local/share/nvim/runtime/plugin/zipPlugin.vim
013.682  000.977: loading plugins
013.824  000.070  000.070: sourcing /home/rice/.local/share/nvim/site/pack/packer/start/nvim-tree.lua/plugin/tree.vim
013.949  000.196: loading packages
014.062  000.112: loading after plugins
014.077  000.015: inits 3
015.485  001.408: reading ShaDa
015.653  000.168: opening buffers
024.156  008.503: BufEnter autocommands
024.159  000.003: editing files in windows
024.208  000.050: VimEnter autocommands
024.210  000.002: UIEnter autocommands
024.211  000.001: before starting main loop
024.693  000.482: first screen update
024.695  000.002: --- NVIM STARTED ---

This log doesn't appear to show the lag

File Structure

├─ nvim/ 
│  ├─ init.lua/       
│  ├─ lua/         
│        ├─ plugins.lua/   
└─

Recreating

nvim config folder:
init.lua:

require('plugins')

lua folder:
plugins.lua:

local execute = vim.api.nvim_command
local fn = vim.fn

local install_path = fn.stdpath('data')..'/site/pack/packer/start/packer.nvim'

if fn.empty(fn.glob(install_path)) > 0 then
  fn.system({'git', 'clone', 'https://github.com/wbthomason/packer.nvim', install_path})
  execute 'packadd packer.nvim'
end

return require('packer').startup(function(use)
  -- Packer can manage itself
  use 'wbthomason/packer.nvim'
  --file managing
  use "kyazdani42/nvim-tree.lua"
  -- theme
  -- use 'shaunsingh/nord.nvim'
end)

Without Plugin

WithoutPlugin.mp4

With Plugin

WithPlugin.mp4
@hamsterBiscuit
Copy link

same as i

@asmallcarrot
Copy link
Author

what tree are you currently using? I've been using a combination of Leexplore and telescope file search.

@kyazdani42
Copy link
Member

cannot reproduce with the config provided, this might be related to your shell (better to set shell=/bin/bash or some fast shell with low configuration when using neovim if you want to avoid perf issues with plugins)

@gegoune
Copy link
Collaborator

gegoune commented Jun 28, 2021

Interesting, never thought of shell setting. Would rather want to keep my fully configured shell for terminal buffers.

Are you saying that each git command nvim-tree executes spawns full shell instance?

@asmallcarrot
Copy link
Author

asmallcarrot commented Jun 29, 2021

currently I'm using the dash shell for /bin/sh and zsh for my shell. I tried bash for both bin/sh and my default shell, lag still persists.

@kyazdani42
Copy link
Member

Hum i had someone with this issue before and he had issues with fish which made the whole tree laggy. I guess when you run system for git commands, it gets slower.
What happens if you disable the git integration in the tree ? does the lag still persist ?

@kyazdani42
Copy link
Member

i might just make the git stuff asynchronous, it might fix number of lag issues

@gegoune
Copy link
Collaborator

gegoune commented Jun 29, 2021

Instant tree with got status showing moments after would be absolutely fine and probably even preferable for me. Just a personal opinion.

@kyazdani42
Copy link
Member

just implemented that in b31003e, could you guys tell me if it changes something ?

@asmallcarrot
Copy link
Author

Still lags just as bad for me.

@gegoune
Copy link
Collaborator

gegoune commented Jun 30, 2021

I cannot remember now what startup time for nvim-tree was before, I am not seeing significant differences between commit above and master, but it[s starting pretty fast for me now.

@asmallcarrot
Copy link
Author

It changed it but no where near what I would consider usable.

@kyazdani42
Copy link
Member

@asmallcarrot could you try disabling git integration fully and tell me if the lag persist ?

@asmallcarrot
Copy link
Author

I went through the readme and was unable to find out how to.

@asmallcarrot
Copy link
Author

I disabled git integration, no difference in lag.

@w0ng
Copy link
Contributor

w0ng commented Jul 9, 2021

@asmallcarrot @kyazdani42 Not sure if it's the same issue, but for my specific case, I could reproduce and it is indeed git causing the lag.

When working on a massive git repo (~1mill files):

$ time git status --porcelain --ignore-submodules -unormal
git status --porcelain --ignore-submodules -unormal  1.05s user 18.28s system 467% cpu 4.134 total

there is a very noticeable delay on startup (after first paint, but before keypresses register),..

I haven't had time to debug this, but lua/nvim-tree/git.luafunctions are running on startup somewhere despite the 3 config values being unset:

vim.g.nvim_tree_gitignore = 0
vim.g.nvim_tree_git_hl = 0
vim.g.nvim_tree_show_icons.git = 0

As a quick test, replacing the contents of lua/nvim-tree/git.lua with:

return {
  reload_roots = function() end,
  git_root = function(path) end,
  update_status = function(entries, cwd, parent_node) end,
  should_gitignore = function (path) return false end,
}

fixes the ~5-10s noticeable delay.

edit: PR added to fix usage of git when not configured #499

@kyazdani42
Copy link
Member

@asmallcarrot closed by mistake, is this issue fixed for you ?

@asmallcarrot
Copy link
Author

asmallcarrot commented Jul 11, 2021

It's better but still takes about 5 seconds to open a file.
I have a ryzen 5 3600XT, 32gb of ddr4 and a 1060 6Gb.
Despite having very few git files on my computer.

@asmallcarrot
Copy link
Author

can you reopen this issue?

@asmallcarrot
Copy link
Author

Just updated to the newest version of nvim, and compiled from source. no luck.

@kyazdani42 kyazdani42 reopened this Jul 19, 2021
@kyazdani42
Copy link
Member

not sure what i can do here i can definitely not reproduce this issue :/

@wincent
Copy link

wincent commented Jul 20, 2021

I've found that a significant source of slowness at startup is that nvim-tree runs an expensive BufEnter autocmd. Here you can see it adding as much as 44ms to startup time (ie. it accounts for about 25% of the total startup time on this machine):

$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
222.912  044.121: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
192.749  026.531: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
218.647  042.927: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
195.251  024.849: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
214.311  042.933: BufEnter autocommands

If I disable nvim-tree, the BufEnter commands drop down to 3ms:

$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
184.679  003.559: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
174.474  003.666: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
169.795  003.691: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
176.531  003.686: BufEnter autocommands
$ rm /tmp/nvim.log && vim --startuptime /tmp/nvim.log -c q && grep BufEnter /tmp/nvim.log
172.143  003.911: BufEnter autocommands

I think I can work around this by lazy-loading nvim-tree the first time I run one of its commands or hit a mapping, but I haven't tried that yet.

wincent added a commit to wincent/wincent that referenced this issue Jul 20, 2021
Because, as reported here:

    nvim-tree/nvim-tree.lua#453 (comment)

it is adding about 40ms to startup time. I'm sure it adds much less
on a faster machine, but on this one (6-year-old, thermal-throttling,
summer-afflicted laptop), it is accounting for about 25% of startup
time.
@fredizzimo
Copy link

For me we are talking about minutes instead of seconds in a special case. I'm managing windows configuration files the same way as dotfiles for linux, and use the WSL2 version of git for doing that, which means that access to the Windows file system is really slow.

So

time winfiles status --porcelain=v1 --ignored=matching
7.45s user 36.59s system 18% cpu 4:03.38 total

Without the --ignored=matching option it is not as bad

0.00s user 0.11s system 20% cpu 0.536 total

Normally I don't open the repository in neovim, but when doing a git commit, the editor hangs for around 4 minutes, which first made me think that something had frozen totally. It also took some time to time to track down to this issue. I didn't suspect that the issue was with nvim-tree.lua, since I never even open the explorer view, and still the hang was there. But once I opened htop and saw that the culprit was git, I just had to do a grep search for the command, and it pointed me to this plugin.

Disabling the git functionality fixes the issue, but I don't want to disable it for my other repositories, since it's quite useful.

I guess it should ideally load the status in the background, or at the very least, load it only when you open the explorer view.

@kyazdani42
Copy link
Member

closing this in favor of #549

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants