-
Notifications
You must be signed in to change notification settings - Fork 328
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
bug: Lazy spawning "too many" git instances on windows #887
Comments
After a bit of thinking while submitting this, I wonder if this issue is actually present on linux machines as well, if they have a very slow network connection. What appears to be happening is that Windows is actually killing the processes after a while, likely to due it believing they are "stale" or "bad". I imagine that the Linux Kernel will do the same thing with "stuck" linux processes if there are a ton of them and they all "appear" to be not moving. Just a theory, I am not completely sure here. |
It's not an issue on Linux and also not an issue on my windows machine. You can configure the concurrency in lazy. See for more details in the readme. |
Fyi: synching takes less than 3seconds for me for over 100 plugins |
I think this is just a Windows issue. Not sure if there's anything that can be done about that. Windows just doesn't seem to be able to cope well with a lot of processes. Lazy just spawns the git processes. On Windows for me it is also slower, but not that much compared to linux. |
You seem to be using https://gitforwindows.org/ This starts git in an emulated bash environment. |
See also git-for-windows/git#4459 |
Could you elaborate on that? What do you mean by "regular git on Windows"? Do you mean you download the git source code and build it yourself? Do you mean wsl git? Or do you mean the windows binaries available for download from git-scm.com (those are the same binaries as gitforwindows.org)?
That shouldn't be the case, unless you're explicitly launching that bash or running a part of Git that is implemented as a shell script. |
As you can see from OP's screenshot, there's a lot of This might also be useful: https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues As I said before, all lazy does is use libuv to spawn a git process. I'm not doing anything special with shells or anything like that. On my Windows 11 system, I don't have any problems. It's a bit slower than linux, but not a big difference. I've also just pushed a change to configure concurrency on Windows by default. It seems that Windows simply can't cope with a lot of processes being spawned. |
Does increasing that timeout also cause lazy to install all (or most) plugins? I'm assuming the |
You can change the timeout in the lazy config as well. |
That is indeed also the same.
Yes, though I assume those are spawned from within the initial
|
Did you check docs and existing issues?
Neovim version (nvim -v)
NVIM v0.9.1
Operating system/version
Windows 10
Describe the bug
When setting up my dotfiles on a windows machine, I notice that Lazy fails to install pretty much any of the plugins I have specified for it. Additionally, my windows machine slows to an absolute crawl for about 5 minutes.
After digging into the task manager, I noticed that there are tons of
Git for Windows
andsh.exe
processes that are being started and killed all the time. I have tested this both on my work laptop (which has an antivirus) and a personal Windows 10 vm (which only has Windows defender) and noticed the same result. A screenshot can be found belowEventually Lazy will just fail with an error by each plugin stating that it was unable to download them
My plugin list isn't exactly "huge", its about 74 plugins. It can be found here though I imagine it will be an issue with pretty much any list of plugins as the issue happens during
git clone
and not setup.If there is more info you need (or if there are things you need tested), please let me know!
Steps To Reproduce
Expected Behavior
I am going to guess that the issue is that Lazy is spawning a new git process for each plugin (maybe all at once, I am not completely sure and haven't really dug into the source of Lazy). Is there a way to configure a limit to the number of processes that are spawned and/or have Lazy use a process pool to reuse processes as opposed to creating new ones? It seems git on Windows is quite a bit slower than git on Linux, which is likely what is contributing to this issue.
It's worth noting that if you manually comment out blocks of plugins and let Lazy setup "less" plugins at once, it does kick through eventually. Basically manually performing the above process limiting.
Repro
The text was updated successfully, but these errors were encountered: