1
Two weeks ago, Babun (CygWin) and Git Bash' shell suddenly became extremely slow. To my knowledge I did not update or change any of these systems when this happened.
When running a simple command as echo test, the response from the command comes immediately, but before the next prompt line appears, I have to wait about 10 seconds.
Now I discovered the weirdest thing today. When I started OBS - my screen recording software - to record this issue, the prompt became as fast as before. I didn't even start recording yet. I only started the application.
After closing the application, the prompt goes back to being slow.
This happens with both bash and zsh.
When I clear all prompt extras by setting PS1='$ ', it also is fast, but running git commands is still slow.
Maybe the issue is that Git waits after every command, but in that case, why didn't it do this earlier, and why did two separate Git binaries have the problem at the same time?
During these tests I was in a directory that did not contain a Git repo.
Update
After more than one month I have not been able to find a solution to this problem, but sometimes it seems to work and other times it does not.
The times Git Bash goes slow, I start using Bash on Ubuntu on Windows, the linux subsystem in Windows. This version of git always seems to work like it should, but I don't like the options of the terminal window that Windows uses.
Joris Molnar
Posted 2017-03-30T11:43:33.203
Reputation: 23
1
If you run something like Process Explorer, you will be able to see what is running while the shell is suspended, including disc activity. It could be a swapping problem, eg fragmented page file or a disc failing in the swap area - check your SMART data, where running another program might cause a different swap area to be used.
– AFH – 2017-03-30T11:54:05.907@AFH Running a SMART check using CrystalDiskInfo shows no apparent issues. I am running this computer on a single SSD, so I don't think fragmentation can be an issue? - I am trying to see the issue with Process Explorer, but all I see is about 5 nested bash processes when running a simple git command. – Joris Molnar – 2017-03-30T12:09:34.627
All those nested processes are liable to cause swapping. Does the prompt reappear only after the other
bashprocesses terminate? – AFH – 2017-03-30T12:22:19.283Yes. While running a command like
git logI see the following tree:bash > bash > git > less. Closing less/log, the tree slowly disappears process after process, and at the same time a second tree is spawned from the topbash(probably prompt?). This tree is also slowly deconstructed and when just the topbashis left, the prompt returns. The second tree looks like:bash > bash > bash > bash > git– Joris Molnar – 2017-03-30T12:46:40.847It's well-know that it is more difficult for an OS to shut down a process than to start it. I don't know how efficient CygWin is at stopping processes: can you try Bash on Ubuntu on Windows 10? I use this now in preference to CygWin, and I haven't noticed performance issues, though I haven't used
giton it - everything I have needed so far has been in the Ubuntu repositories, and I have installed it withapt-get. – AFH – 2017-03-30T13:28:55.910What I notices when using Process Explorer, was that the commands slowly disappear slowly after each other. When I have the OBS recorder screen open and stop the
git log, the processes appear and disappear quicker than Process Explorer is able to show, so there is no problem. - Using the Bash on Ubuntu on Window does work fast, with or without OBS running. – Joris Molnar – 2017-03-30T14:53:05.640Sorry, I can't think of another cause. I have encountered this sort of behaviour in the past, and it was always swapping-related. The nested
bashinvocations will be becausebashlaunches a new process to execute a script (unlessexecis used). – AFH – 2017-03-30T15:07:19.887Thanks for your help in diagnosing the issue. If I can't figure it out, I guess the last option is to do a complete system reinstall. A proper working git is just too important. – Joris Molnar – 2017-03-30T15:20:04.747
Another option might be to use the Windows port git.exe: there is a portable version, if you want to try it without installing anything.
– AFH – 2017-03-30T16:04:04.407In the main question I state I tried Git Bash. With that I meant the Git for Windows port - The weird thing is that this issue happens with both versions of Git (Cygwin & msys2). Even the Git that comes bundled with tools like Sourcetree and Visual Studio is affected by this issue - It seems every git command, even
git --versionwith an empty prompt, has a large delay after the command completed. (I immediately get the version, but it waits a while before the prompt is completed) – Joris Molnar – 2017-03-30T19:48:25.380I was responding to your comment "A proper working git is just too important", and suggested a possible alternative which does not require CygWin, and may be more efficient in a Windows/cmd environment. If the delay happens with all
– AFH – 2017-03-30T23:13:32.370gitversions, maybe it's caused by a network time-out, but you would need a network monitor like Wireshark to verify this.