Git: bash.exe and git.exe :git bash and git prompt is very slow due to the parsing of .git directory

[microwan]

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.13.0.windows.1
built from commit: eba7af3dbb4c846c6303c5f64102acee696c9ab0
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

** insert your machine's response here **

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Path Option: CmdTools
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

Just launch git-bash or bash

• What did you expect to occur after running these commands?
  it should be fast less than 1s

• What actually happened instead?
  it is very slow due to that bash.exe , git.exe are trying to go in each .git directories
  (more than 10s)

Cf Process Monitor logs.
Logfile_BASH.zip
After checking the Safe DLL Search
in each process, bash.exe,git.exe is trying to parse all my .git repository.
it can multiply bash.exe and git.exe by 10 when you have a lot of repos.

I suspect a bad strategy to search the dll files for bash.exe, git.exe

[dscho]

My Bash definitely does not try to find each .git directory.

It looks like a couple of bash.exe processes are spawned, which makes me suspect that there is a ton of stuff going on in either your $HOME/.bash_profile or your $HOME/.bashrc.

In any case, there is a decent chance that https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues can help you investigate further.

[microwan]

Hello ,

.bash_profile and .bashrc are empty
some people in my company have this issue.
All the git commands or bash commands are slow (more than 10s)
2 assumptions :
1) I suspect the DLL Research strategy in bash.exe not well configured. (SafeDLLSearchMode)
2) Or Antivirus issue could be too heavy for git bash.
UPDATE : After disabling the AntiVirus "Symantec" , the problem is still there.. git bash is very slow

There are something to improve or to optimize the DLL research in git-for-windows.

              Best regards

                              Erwan

[dscho]

Why would the DLL search and/or the AV look into .git/ directories?

[microwan]

Hello Dscho ,

No, AV does not look in .git directories .. I have disabled it .. .git directories are still scanned.
It is maybe Windows tuning or git bash issue (DLL Strategy Search in the application itself)
it is a endless issue between git windows and git linux.

https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64

3 people in my neighboorhood have the same issue.
10s for a each git command can slow down our jenkins jobs.

i have tried to tune SafeDllSearchMode in registers windows to improve the bash and git efficiency.
it is still slow.

Best Regards

          Erwan

[dscho]

I think this whole DLL search is a real big real red herring.

I see in the log that quite a few processes are spawned from the initial Bash, and that there are substantial gaps when spawning. Which makes me think that the real culprit is most likely some shell scripting that spawns subshells or some such.

My Git Bash here is pretty fast, except when the domain controller cannot be reached...

[bbolli]

Try resetting the Bash prompt: https://stackoverflow.com/a/4485396/232775

[microwan]

Hello ,

I am reinstalling everything on SSD (Windows + git bash)
but some collegues have the same issue.. on old HDD.
i will try to launch process monitor to compare the Dll Search Strategy.
12s for a "cd" or a "ls" .. too long

[dscho]

i will try to launch process monitor to compare the Dll Search Strategy.

No idea why this DLL search strategy keeps coming up. As far as I can tell, the DLL search strategy has nothing to do at all whether .git/ directories are enumerated or not. There are no DLLs to be found there, anyway.

[microwan]

There is an interesting article in SearchDll

1) SafeDllSearchMode
The standard DLL search order used by the system depends on whether safe DLL search mode is enabled or disabled. Safe DLL search mode places the user's current directory later in the search order.

2) KnownDLLs

Before the system searches for a DLL, it checks the following:
If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL's dependent DLLs, if any). The system does not search for the DLL. For a list of known DLLs on the current system, see the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx

Is it possible to analyze the Dll Search Strategy in Git Bash source code ?
because some people in my company are complaining on git (windows)

[dscho]

And why, exactly, are only .git directories searched? Are they in the PATH?

All this makes no sense...

[lhasadad]

I want to point out that the search of files in the .git directory may be part of normal git command processing. Its checking configuration information in the earlier screen grabs that were posted. one thing I did not see anyone do is look at any points in the module trace where there are long periods between entries or associated with a particular action. Has that been done yet?

FWIW this DLL search thing is not likely your issue. all it means is that the git executable has been linked to load a DLL and its tracking it down. the file open/closes etc in the .git directory are not related to DLL acquisition.

[appelgriebsch]

Same issue here... starting Git Bash on Windows 10 Creators Update take ages (longer than 5 sec.), any git command that is triggered by GUI clients (such as GitHub Desktop or Tower) is also taking a lot of time to response (sometimes the apps were set to 'Not responding' when doing Git operations). Its really annoying...

[appelgriebsch]

When opening a local Git repo in Tower (http://gittower.com) the following set of processes are spawn in the background. Each of these are running for more than three seconds on my system (Core i7, 2.5 GHz, 16 GB RAM), increasing the overall time to build up the information displayed in Tower...

Not sure why this happens. On my work notebook (W7 Enterprise, Core i5, 16 GB RAM) the system behaves normally and the Tower UI will be assembled within a second or two...

If there is an idea how I can profile what's going on, pls. drop me a note.

[appelgriebsch]

Looks like it is somewhat related to a recent driver update on my Lenovo Thinkpad. Make a clean Win 10 (1703) install (incl. recent Microsoft OS updates) and everything is working as expected. Install recommended driver updates via Lenovo Update Checker, reboot and problem comes up again. So fix for me is to not install any Lenovo updates actually.

[adambernstein]

Thanks for the update here @appelgriebsch! I realized this issue occurs on my personal Lenovo machine, though I use a different Lenovo Thinkpad for work and have had no issues on this machine. Will try your suggestion later and report back.

[dscho]

Here are a few hints. You can typically see the command-line of these sh.exe processes either by using ps -fs or wmic process list. Also, I highly suspect that those sh.exe processes are spawned from the Bash startup process, in which case this hint applies.

[microwan]

Hello @adambernstein , @appelgriebsch ,
on windows 7, you can use Process Monitor (on process name equals to git.exe) to check why there is the slow git latency .

[dscho]

I marked this with the "help wanted" label because I think I ran out of options how I could help. The Process Monitor suggestion is a good one.

[adambernstein]

Finally had a chance to really sit down and thoroughly test this. I went through every running service and process in the machine and turned them off one by one and tested how long it took to get an input prompt. Long story short, it turned out to be the AMD/Radeon display adapter hardware. While uninstalling Radeon management/settings software did not help, _disabling my AMD Radeon R7 M460 display adapter in the device manager solved the issue._

For reference my machine is a Lenovo Ideapad Flex 4 1580 running Windows 10 and git for windows version 2.15.0.

Before disabling the graphics card, the time for the initial prompt to be available was 10-12 seconds, and the time for each command to return to the prompt was about 3s.
After disabling, both the terminal startup and any command instantly go to the prompt. It's unreal!
Hope this helps someone out there.

[dscho]

It's pretty weird that a display adapter driver can cause this... Glad you found out what it was @adambernstein!