2-12 second freeze on closing buffers (or opening a file in snacks picker)

[aldanor]

Traced it down to gitsigns via profile.nvim:

Closing buffer:

Snacks picker:

Default gitsigns config (coming with lazyvim default config, I believe).

Didn't happen previously and started at some point, so I'd suspect some changes in gitsigns (because snacks hasn't been updated in over 3 months). I could try git bisecting it I guess...

Might be related: #1029, #1015.

[canova]

I had the same issue this week and profiled using plenary.nvim's jit.p profiler wrapper. Here's a profile I captured:
https://share.firefox.dev/4e9dKTI

The issue only starts to be noticeable when I leave neovim open and use it actively for a while.

I noticed the issue when I was opening the fzf-lua file/buffer pickers. This profile is a capture of opening fzf-lua buffer picker twice.

[zoriya]

For me this makes other git plugins super slow (especially telescope or snack.picker with git_status). The longer your nvim is open the more this becomes noticeable, and you basically need to restart nvim every day to make your git usable again.

This bug has been present for a while but i first thought it was a telescope issue and noticed it was not when switching to snack recently.

[lewis6991]

Doesn't affect me. Issue needs more info, e.g. precise reproduction steps with minimal configuration (not lazyvim).

[canova]

I actually tried enabling this plugin again yesterday and noticed the same issue again today. I had this extension disabled and tried to use other extensions in the meantime but I didn't like any of them, so I came back to this plugin again.

Here's some information in case it could be useful for debugging:

I captured another profile (using jit.p): https://share.firefox.dev/40q1kkR

In this 2 seconds profile, I just opened fzf-lua picker and waited until it's visible. 59% (43% from the first tree node and 16% on the second) of the time is spent inside gitsigns, which is nearly 1.2seconds.

Here's the heaviest stack, which is 40% of the time spent:

/home/linuxbrew/.linuxbrew/Cellar/neovim/0.11.3/share/nvim/runtime/lua/vim/_system.lua:spawn
(root scope) /home/linuxbrew/.linuxbrew/Cellar/neovim/0.11.3/share/nvim/runtime/lua/vim/_system.lua [/home/linuxbrew/.linuxbrew/Cellar/neovim/0.11.3/share/nvim/runtime/lua/vim/_system.lua:338]
pcall
/home/canova/.local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:_resume
(root scope) /home/canova/.local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua [/home/canova/.local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:307]

It gets triggered from async.lua:307 initially, and then async.lua:_resume which triggeres spawn eventually. But I don't know where this async _resume comes from as I don't know the codebase. I might try profile.nvim next time to see if it gives me more insight.

Some more information in case it can be useful:
nvim version: v0.11.3
LuaJIT 2.1.1748459687
gitsigns version: current main
Platform: Linux - Ubuntu 24.04.2 (I will try on macOS a bit to see if I can reproduce, but I think on Linux it was more visible)

I don't know if it's a recent regression but my nvim config history shows that I started using this plugin around May 2024 and was happy for a year or so. Not so sure if I just failed to notice before. I might try to bisect it, but it's pretty difficult to do because you have to wait for a day or so for each bisect iteration.

I hope we can find the root issue and fix it because this is one of my favorite plugins and I would love to be able to use it again! And thanks for this great plugin!

[lewis6991]

The only thing I can think of is that maybe these pickers are loading lots of buffers and Gitsigns is trying to attach to all of them.

There was a similar issue with vimgrep that I had to add special handling for.

[lewis6991]

If someone followed the issue template (like OP should have). Someone might be able to provide some useful information, e.g. Gitsigns debug messages.

[canova]

Ah, I can reproduce this issue quite faster now. I open the Firefox codebase and navigate for a while using LSP (go to definition/declaration/reference) in some C++ code.

Here are the debug messages I captured: https://gist.github.com/canova/3dd5852d6f52fc803c319a080dd4f098
What I did:

• Ran :Gitsigns clear_debug
• Opened fzf-lua "buffers" picker
• Closed it.
• Ran :Gitsigns debug_messages

I'm surprised by the amount of watchman messages. I'm using watchman since the Firefox repo is quite large and without it most operations are quite slow.

[lewis6991]

Yeah, looks like the file watcher is getting lots of activity, and we open a watcher per buffer atm. Gitsigns does debounce and file events, but even so there's a lot going on in there.

There is plans to only maintain one watcher per gitdir but haven't got around to finishing that yet.

I guess I could try opening some files in the Firefox repo and try fzf-lua.

Can you give me a tldr on how to setup watchman?

[canova]

We have a bootstrap command in the Firefox codebase that lets you set up watchman etc. automatically. After pulling Firefox from here. You can run ./mach vcs-setup (requires python3) to set up watchman (and it does a few more things but it shouldn't be invasive and should ask you before changing stuff).

You might need to install watchman before (brew install watchman, apt install watchman etc.)

It essentially adds a new config entry inside .git/config and sets up a watchman script inside the hooks directory. Something like core.fsmonitor = /home/user/projects/firefox/.git/hooks/query-watchman

For other projects, you might need to do these (after installing watchman):

• cp .git/hooks/fsmonitor-watchman.sample .git/hooks/query-watchman (that sample should be there already)
• git config core.fsmonitor /path/to/your/project/.git/hooks/query-watchman

Then run git status, and you if you run watchman watch-list after it, you should be able to see that your project is being watched now.

[canova]

FWIW, I added this to my setup config and the performance issue seems to be gone for me:

watch_gitdir = {
    enable = false,
},

These are the debug messages with the same STR above after this config is added:

18676433.63 D detach(380): Detached
18676433.69 D detach(380): Cache was nil
18676435.19 D attach(380): Attaching (trigger=BufFilePost)
18676435.81 D attach(380): Non-normal buffer
18679291.92 D cli.run: Running action 'debug_messages' with arguments {}

But I don't know which functionality I lost by adding this 😄 Seems like most of the things I care about are working for now. (maybe moving files around will be glitchy? but I think that's okay for me for now)

Maybe others who had this issue can add this to their config to see if it helps, just to see if we have the same root issue.

[lewis6991]

I've been able to reproduce the firefox-watchmen issue.

The main problem is that opening any buffer causes git show on every other open buffer, which is very slow in a big repo like linux.

I've merged #1374 which should help but not fully resolve this. Please let me know if it helps (or doesn't).

[canova]

Awesome, thanks a lot for the fix! The performance issue seems to be fixed on my end with the same STR!

[lewis6991]

Also merged 2bf0f73 which prevents the issuing worsening with the amount of buffers.

Considering this completed. Will reopen if needed.