I have been debugging why in some of the folders my plugin fff scan is very contended and sometimes very slow on a large git repo and as appeared the reason is this function
|
local function watch_gitdir(dir) |
|
-- Stop if there is already a watcher running |
|
if watchers[dir] then return end |
|
|
|
---@type userdata |
|
watchers[dir] = vim.loop.new_fs_event() |
|
watchers[dir]:start( |
|
dir, |
|
{ recursive = true }, |
|
vim.schedule_wrap(function(...) on_throttled_change(dir, ...) end) |
|
) |
|
state.current_watcher_dir = dir |
|
end |
you are setting recursive watcher on the .git folder unconditionally in case of chromium monorepo the .git folder is 64GB and 700k+ object files inside - this exhauses the file system watcher, adds a lot of VFS load and simply unnecessary
Instead you can watch specifically one file .git/index - you can watch exatly one path and keep the exact functionality untouched
I have been debugging why in some of the folders my plugin fff scan is very contended and sometimes very slow on a large git repo and as appeared the reason is this function
git-conflict.nvim/lua/git-conflict.lua
Lines 458 to 470 in a1badcd
you are setting recursive watcher on the
.gitfolder unconditionally in case of chromium monorepo the.gitfolder is 64GB and 700k+ object files inside - this exhauses the file system watcher, adds a lot of VFS load and simply unnecessaryInstead you can watch specifically one file
.git/index- you can watch exatly one path and keep the exact functionality untouched