Find File: Extraneous git status

[alex-courtis]

Description

When finding file a "git sync job" is performed for all directories up the tree. This is a performance problem.

Originating discussion: #2275

Neovim version

:; nvim --version
NVIM v0.9.1
Build type: Release
LuaJIT 2.1.0-beta3

Operating system and version

Linux 6.3.9-arch1-1

nvim-tree version

3cc698b

Clean room replication

vim.g.loaded_netrw = 1
vim.g.loaded_netrwPlugin = 1

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvt-min/site]]
local package_root = "/tmp/nvt-min/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
  require("packer").startup {
    {
      "wbthomason/packer.nvim",
      "nvim-tree/nvim-tree.lua",
      "nvim-tree/nvim-web-devicons",
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. "/plugin/packer_compiled.lua",
      display = { non_interactive = true },
    },
  }
end
if vim.fn.isdirectory(install_path) == 0 then
  print "Installing nvim-tree and dependencies."
  vim.fn.system { "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path }
end
load_plugins()
require("packer").sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua setup()]]
vim.opt.termguicolors = true
vim.opt.cursorline = true

-- MODIFY NVIM-TREE SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
_G.setup = function()
  require("nvim-tree").setup {}
end

Steps to reproduce

Clone [email protected]:torvalds/linux.git
Open nvim-tree
:e arch/powerpc/boot/dts/fsl/b4420qds.dt

[2023-06-25 14:03:44] [profile] START find file /home/alex/src/linux/arch/powerpc/boot/dts/fsl/b4420qds.dts
[2023-06-25 14:03:44] [profile] START refresh_nodes_for_path /home/alex/src/linux/arch/powerpc/boot/dts/fsl
[2023-06-25 14:03:44] [profile] START git sync job /home/alex/src/linux /home/alex/src/linux
[2023-06-25 14:03:44] [git] running job with timeout 400ms
[2023-06-25 14:03:44] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u /home/alex/src/linux
[2023-06-25 14:03:44] [profile] END   git sync job /home/alex/src/linux /home/alex/src/linux 114ms
[2023-06-25 14:03:44] [git] job success    /home/alex/src/linux /home/alex/src/linux

...

[2023-06-25 14:03:44] [profile] END   reload /home/alex/src/linux/arch/powerpc/boot/dts/fsl 6ms
[2023-06-25 14:03:44] [profile] END   refresh_nodes_for_path /home/alex/src/linux/arch/powerpc/boot/dts/fsl 330ms
[2023-06-25 14:03:44] [profile] START draw
[2023-06-25 14:03:44] [profile] END   draw 14ms
[2023-06-25 14:03:44] [profile] END   find file /home/alex/src/linux/arch/powerpc/boot/dts/fsl/b4420qds.dts 345ms

Expected behavior

No response

Actual behavior

No response

[alex-courtis]

@linrongbin16

I'm able to reproduce the issue. 345ms in the above logs is the result of 6 possibly unnecessary git status calls, which are synchronous.

[alex-courtis]

#1731 #1723 #1716 were the drivers behind the the refresh:

nvim-tree.lua/lua/nvim-tree/actions/finders/find-file.lua

Line 33 in d8b154c

-- we cannot wait for watchers to populate a new node

Possibilities:

• Execute this refresh only when the folder is present but not the file. The regular discovery process following that is fast and does not involve synchronous git refreshes.
• Remove refresh_nodes_for_path and try once again work the folder refresh into the iterator.

[linrongbin16]

really thanks for your work!

[alex-courtis]

really thanks for your work!

Thanks for pushing me on this one; you've surfaced a real performance issue that has not been visible until now.

I'd be most grateful if you tested the fix for the next week:

cd /path/to/nvim-tree.lua
git pull
git checkout 2293-find-file-extraneous-git-status-calls

refresh_nodes_for_path has been removed, however I would be grateful if you could watch the find time e.g.

[2023-06-25 14:03:44] [profile] END   find file /home/alex/src/linux/arch/powerpc/boot/dts/fsl/b4420qds.dts 345ms

[linrongbin16]

I will try day after tomorrow

[linrongbin16]

Hi, @alex-courtis , this branch looks good to me, quite performant now!