-
-
Notifications
You must be signed in to change notification settings - Fork 610
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
Application slow closing directories with .git contained #2997
Comments
As mentioned, this issue happens when a sub-directory contains e.g. the following structure triggers the issue
|
Sorry, not able to replicate this one on linux. Attempt:
Collected a log, normalised and compared to yours: : ; uudiff 2997.log actual.log
--- 2997.log 2024-11-10 09:23:53.799669092 +1100
+++ actual.log 2024-11-10 09:33:13.543302474 +1100
@@ -1,32 +1,36 @@
[profile] START core init /tmp/treedebug
[watcher] Watcher:create '/tmp/treedebug' nil
[watcher] Event:create '/tmp/treedebug'
[watcher] Event:start '/tmp/treedebug'
[profile] START git toplevel git_dir /tmp/treedebug
[git] git -C /tmp/treedebug rev-parse --show-toplevel --absolute-git-dir
-fatal: not a git repository (or any of the parent directories): .git
+fatal: not a git repository (or any parent up to mount point /)
+Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
[profile] END git toplevel git_dir /tmp/treedebug ms
[profile] START explore /tmp/treedebug
[profile] START populate_children /tmp/treedebug/dummy.go
[profile] END populate_children /tmp/treedebug/dummy.go ms
[profile] START populate_children /tmp/treedebug/main.go
[profile] END populate_children /tmp/treedebug/main.go ms
[profile] START populate_children /tmp/treedebug/subdir
[watcher] Watcher:create '/tmp/treedebug/subdir' nil
[watcher] Event:create '/tmp/treedebug/subdir'
[watcher] Event:start '/tmp/treedebug/subdir'
[profile] END populate_children /tmp/treedebug/subdir ms
[profile] END explore /tmp/treedebug ms
[profile] END core init /tmp/treedebug ms
+[profile] START view open
+[profile] END view open ms
[profile] START draw
[profile] END draw ms
-[profile] START reload /tmp/treedebug
-[profile] END reload /tmp/treedebug ms
[profile] START git toplevel git_dir /tmp/treedebug/subdir
[git] git -C /tmp/treedebug/subdir rev-parse --show-toplevel --absolute-git-dir
-fatal: not a git repository (or any of the parent directories): .git
+fatal: not a git repository (or any parent up to mount point /)
+Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
[profile] END git toplevel git_dir /tmp/treedebug/subdir ms
-[profile] START reload /tmp/treedebug/subdir
-[profile] END reload /tmp/treedebug/subdir ms
+[profile] START explore /tmp/treedebug/subdir
+[profile] START populate_children /tmp/treedebug/subdir/.git
+[profile] END populate_children /tmp/treedebug/subdir/.git ms
+[profile] END explore /tmp/treedebug/subdir ms
[profile] START draw
[profile] END draw ms That I'd be grateful if you can perform some further tests:
|
Rolling back to minor versions: cd /path/to/nvim-tree.lua
git pull
git checkout v1.7.0 When you're finished testing: git checkout master |
Hey Alex, thanks for looking into this RE gitconfig, it doesn't look like theres anything in there that would be causing this kind of effect, but in case, you can find a copy here. I'll update this comment once I've had a chance to run the additional tests. Edit: testing the above results in the following, in a path in my home directory, using the cleanroom config Disabling the above changes and testing with previous versions
|
git toplevel takes 25ms, for me (linux) it's 5ms, however that's not a great issue. You might want to try git fsmonitor daemon
Matches my times. It seem that the issue is the filesystem watchers, specifically closing them. Are you running any virus scanners or similar file system monitoring daemons? |
This might be a vim problem. Please try this: mkdir "${HOME}/fs_event_test"
cd "${HOME}/fs_event_test"
touch {1000..9999}
nvim
Creation should be near-instant. /tmp/foo.lua: local fail
local FS_EVENT_FLAGS = {
stat = false,
recursive = false,
}
local function create_fs_event(path)
-- print("create_fs_event: " .. path)
local fs_event
fs_event, _, fail = vim.loop.new_fs_event()
if not fs_event then
print(path .. " " .. fail)
os.exit(1)
end
local rc
rc, _, fail = fs_event:start(path, FS_EVENT_FLAGS, function()
print("callback " .. path)
end)
if rc ~= 0 then
print(path .. " " .. fail)
os.exit(2)
end
end
for i = 1000, 9999, 1 do
create_fs_event(tostring(i))
end
print("created all events successfully") |
I can confirm this issue on the following setup:
To reproduce the issue, I needed to open a few directories and a file. Here is a performance profile captured while browsing the |
Thanks for the additional info; I'm not quite sure what to do with it or how to read the profile output. Did you perform this test? #2997 (comment) We need to isolate whether this is an nvim-tree issue or a neovim issue, by attempting to replicate without nvim-tree.
What exactly needs to be done? How would I replicate this? I'll need full instructions on the profiler and how to read it. |
@alex-courtis sorry for the confusion. I will hopefully have the time to add some instructions later. I will run the test in #2997 (comment) as soon as I am home from work. |
FWIW @michaelvanstraten's change here fixes this for me, though that's obviously a nuclear option. |
@TrevorHinesley i did the same, thank you. |
I also do that for one massive repo that I work on when using macos: https://github.com/alex-courtis/arch/blob/497777f10727f7f4ff4f85a903168054f878e051/config/nvim/lua/amc/plugins/nvt.lua#L217 |
Description
After upgrading to 0.10.*, closing nvim causes a long pause, up to 10 seconds.
This seems to be similar to #2438, but it is replicable with zero changes made to the cleanroom config, and is not related to
node_modules
or any similar large directory.This is replicable using the absolute barebones cleanroom config without any changes made.
There appears to be no relevant info in nvim-tree.log as all logged lines occurs before the attempted close.
This behaviour has two interesting cases
.git
directory, the bug occurs, it does not only apply to the root open path.git
directory simply exists without being an actual git repoNeovim version
Operating system and version
MacOS 14.1
Windows variant
No response
nvim-tree version
c763948
Clean room replication
Steps to reproduce
Expected behavior
Standard close behavior.
Actual behavior
A hang/delay of up to 10 seconds before nvim closes.
The text was updated successfully, but these errors were encountered: