Slow in a repo with large working tree #147
Comments
|
I ran through the test and I don't have an issue if I follow the instructions exactly, but ti will freeze up if I open the This is a known issue with adding file watches to a git directory, because it throws off change events constantly. I have a check for Does this sound like it may be the issue? If not, can you please include your neo-tree config and try capturing a log file with the instructions here: https://github.com/nvim-neo-tree/neo-tree.nvim/wiki/Troubleshooting#logs |
|
Oh, and thanks for the kind words! |
|
Thank you.
Maybe not. Let me make my example above clearer. :) Throughout the process, I stay under I will put a short video below for demo. https://asciinema.org/a/elRuwAgal79z09hL5bWGIM9sC
I didn't config it. What I did is install I will attach the log info below Thanks a lot. Update: Another experiment: Thank you very much. |
|
I think the problem is with the require("neo-tree").setup({
filesystem = {
filters = {
respect_gitignore = false,
}
}
})and letting me know if that fixes the problem? if it does we may be able to throttle or cache that check. |
|
Here is the command that is actually run to get the ignored files: |
|
Thanks.
I can confirm that after setting Thanks a lot. |
Maybe, I will try out different strategies and see if there is a better way. We may have to add options that trade accuracy for performance. The built-in plenary filter that we used to use is likely better performing in this situation, but not always accurate. The hard part was figuring out exactly where the issue was. The rest should be downhill from here. |
|
It makes sense. Thank you very much for developing and maintaining this plugin. I will use it with |
rockyzhang24
changed the title
|
Or is it possible to make the process of checking gitignore asynchronous? |
|
You know, I checked out the linux repo, which is insanely huge, and I had no performance issues. I think the problem with the bare repo as you have configured it is that there is a large amount of untracked but eligible files. I bet if you just add an appropriate .gitignore file that would solve the issue. In this case, you might want to .gitignore everything and then only track what you explicitly add, or add an exclusion just for certain folders which you do actually want to track. If you are using the bare repo for dotfile management, I would highlly recommend using dotbot instead. I'll still add an alternative respect_ignore option, but I also wanted to throw this out there. |
|
... but if you do keep your bare repo as-is, update to the latest in main and add this option to enable the alternative gitignore logic: require("neo-tree").setup({
filesystem = {
filters = {
respect_gitignore = true,
gitignore_source = "plenary"
}
}
}) |
|
Thank you so much for you help and suggestions.
Lol, yesterday I tested it with linux repo (more than 5GB) as well. I opened the In order to make the working tree large enough, in the shell rc file, I only set In my original experiment, I set both
But I need to see the whole structure of
Yes, I am using bare repo to mange my dotfiles. And actually I set
I tried this option and the performance is great with Sorry for this verbose reply, and really appreciate your patience for helping me debug this. :) |
The major issue with this is that it only works when your cwd is the root of the repo, otherwise it doesn't find the ...actually, now that I read that I realize it's worse than I remember. It only works for the root level objects... I'll need to revisit this. |
|
Okay. Thanks ❤️ For my verbose relay above, I want to extract and summarize the problems so far below to make it clear for your reference. For all situations below, use
Thank you very much. |
|
One more idea (let me know if it is better to open a new issue): require("neo-tree").setup({
filesystem = {
filters = {
respect_gitignore = true,
gitignore_treatmente = 'symbol' -- can be 'hidden' or 'symbol'
}
}
})For the symbols, I think this is a good addition to |
That definitely resulted in a delay but but I only had a long delay the first time, and after that it was about 1 second. I think the cache is more effective on my computer, maybe because it is clean or I just have a lot less files in my HOME directory. Whatever the case it is still enough to make an obvious delay but not to the degree that you are seeing.
I don't have that, but it could be that you are still getting a significant delay from the git status step. I just committed a new option in main that runs require("neo-tree").setup({
filesystem = {
filters = {
respect_gitignore = true,
--gitignore_source = "git status", -- <-- this is the default
gitignore_source = "git check-ignore",
}
}
})
Can you try it out and let me know if it is improved? |
No, still very long latency. What I did is bit by bit is:
After pressing |
|
As a test, can you run |
|
No delay, it exits immediately with |
|
This means I am either on the wrong path, or I fixed one slowdown but another one remains. The next question is, how long does this take: |
|
Thanks for the explanation and apologize my wrong understanding for exit code.
It outputs contents under my And then I run |
|
There's the problem! This is used to mark the status of each item shown in the tree. I guess the problem here is that there are so many untracked files. Maybe I can come up with an alternate solution that only checks the files that are currently visible. I'll look into it. |
|
I just merged a new require("neo-tree").setup({
enable_git_status = true,
git_status_async = true, -- <-- this is the new setting
filesystem = {
filters = {
respect_gitignore = true,
gitignore_source = "git check-ignore",
}
}
})
Please try it out and let me know how it works. |
|
Thanks. Now, the latency issue is totally resolved. After I press However, if I change Thank you. |
Yes, this is a two part solution for a large repo. Checking ignore and status can each add their own delay. I think I will make both of these settings the new default soon, but I want to use it for a week to make sure there are no issue.
I'm pretty sure nvim-tree has already made the switch to an async git status. I just put it off until someone expressed a need because it always worked fine for me as it was. 🤷♂️ |
|
I'm happy to see that this discussion continues. I have also experienced the same recently but I was too busy to report it. Thanks for the OP btw :) |
|
@cseickel Thank you. Thank you very much. |
|
The plenary option technically still exists but it is too flawed to be useful so it won't be documented and can be removed at any time.
|
|
Thank you so much for the explanation. Now |
|
Thanks for you guys making this plugin better! @cseickel @yanzhang0219 |
|
Hi @cseickel Update this issue:
I am using the latest nightly neovim and latest neotree with default config. I also found nvim-tree is very fast when fetching git status and diagnostics no matter how large the repo is. Probably you could investigate it and find a workaround. Thank you. |
Hi, this plugin is awesome. Great ideas on filtering and sources, easy to customize and extend, and very active development. Thank you first.
To reproduce this issue:
git init --bare $HOME/bare.git$HOME, let's create a file, and commit ittouch file1 git add file1 git commit -m "first commit"neo-treevia:NeoTreeRevealToggle. Now it freezes there. After around 2~3 seconds, theneo-treewindow opens.neo-treewindow open, we modify this file. Finally we save it via:w. After pressing<ENTER>, Neovim freezes again.It seems that
neo-treefetches the git info synchronously, so Neovim will block in a bare repo with a large working directory. Is it possible to deal with this situation?Looking forward to your response, and thank you so much.
The text was updated successfully, but these errors were encountered: