2.11.1 slow enough to make it unusable in Windows 10 x64 - upgraded from 2.9 lighting fast

[aram535]

Hi, Who actually supports the bash shell itself? That's what's really slow on my machine and not any particular git command.

With 2.9.(?4?) installed I had instant access to the shell prompt and commands. With 2.11.1 installed it takes 15 seconds (measured on iPhone stopwatch) to get the prompt after launching.

Running a command results in a quick response (i.e. git --version --build-options) however after the output of the command the shell sits there for another 4 seconds before the prompt is presented back.

I have disabled both .bashrc and .bash_login scripts so the shell is running clean.

This is on Windows 10 x64.

[aram535]

Sorry two more things I have tried. 1) I have also renamed the .gitconfig to .gitconfig.disabled 2) I added e:\apps\git-2.11.1 to Malwarebytes Pro exclusion and even tried uninstalling MalwwareBytes Pro.

[fourpastmidnight]

I have noticed this, too, of late. It was reported once before on a previous issue a while back. In my case at that time, the issue was present for a day, and then mysteriously went away. But for the past few releases, this condition has been consistently true.

I haven't, however, had time to look into it myself.

[juliankopkalarsen]

This looks like what I am experiencing in #1070. Does downgrading back to 2.9 help ?

[fourpastmidnight]

So, the issue I had reported this on a while back was #786. Like I said earlier, it was there for a day, and then gone. However, recently, it's been pretty bad.

I remembered that relatively recently I had updated my Trend Micro Maximum Protection anti-virus and firewall booster program. I have never had a problem with it before, but I decided to check it out anyway. On a whim, I decided to add the path to my Git for Windows installation to the list of exceptions (i.e. Trend Micro won't scan this folder or perform threat detection on it). And lo and behold, the Bash shell has sped up with respect to returning the prompt after issuing commands. It would appear that my anti-virus program has been gumming up the works.

This seemed to resolve the issue for me. I see that @aram535 took similar steps with his security program, but unfortunately, it didn't seem to improve his results, so I guess YMMV.

[aram535]

Yeah I have had Malwarebytes on my machine since the start, but I recently upgraded to the Pro version (more checks). I did add the git path to the exception list - even went as far as uninstalling it - to no avail.

I have been meaning to rebuild my machine anyway, so this maybe a good time to do as a test to see if the same problem occurs. That'll at least tell me if it's Windows or not. It almost feel like it's trying to access a resource or disk that isn't available .... it's acting like when a linux system has a failed NFS mount or something so that every command works but takes forever to complete.

Will report back once I get a chance to rebuild the system ... probably end of the month.

[dscho]

it's acting like when a linux system has a failed NFS mount or something

Oh, you know what it could be? A hard-to-reach domain controller. If you set the environment variable HOME to point to your home directory, it may fix the problem.

You did not fill out the issue reporting template (that is designed to answer important questions regarding your setup), so I have no idea what terminal you use (Bash? CMD? Powershell?) and that puts more of the burden on you to test things out yourself.

You may find the culprit by using the advice in https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues.

Or maybe just open a cmd window, cd "\Program Files\Git\usr\bin" and then strace bash -l -i (if it hangs at some stage, that is a strong indicator that something in the MSYS2 runtime takes a lot of time).

[adamwalling]

https://github.com/google/UIforETW can be a great way to investigate and diagnose issues like this on Windows machines, but it requires a pretty high level of technical competency. Process Monitor is friendlier but not as powerful, but may still help uncover the underlying problem.

[thedbexp]

I found this bug and bug 1070 related to what I'm seeing on my own machine. I have yet to try disabling the Radeon driver, but what (temporarily) fixed the problem for me is:

1) unpack portable git on an accessible folder 2) create a new user that has rights to that folder 3) login as the new user 4) start git-bash as the new user 5) switch back to your main user and launch git-bash

Something with using git-bash as a "clean" user seems to fix the slowness of git bash of the main user on my computer. I tried clearing out my home directory and adding things back one by one, but the bash prompt is fast and responsive no matter what is in my user directory once the "clean" user logs in to git-bash for the first time.

I haven't had the time to troubleshoot why this is just yet, but I wanted to add that information in case it resolves the problem for anyone else which might lead to a fix or a reason that this is happening. When I get a moment, I'll try tracking this down a little better. For now, the second user account works well enough for me to get back to working.

[trowpa]

I can confirm that the Radeon driver issue is real. Oddly - if i simply bring up the Radeon Settings Gui and click on it while waiting for waiting on the prompt to appear in minTTy, it appears IMMEDIATELY.

It doesn't even seem to matter what I do on the settings app - just clicking on a navigational link seems to release the git bash for some reason - almost as if it wakes it up, brings it to the foreground, or something - very very weird.

I've contacted AMD Tech support - will report back if anything useful comes of that. Otherwise, i may just end up disabling the AMD driver.

FYI - i am on a Dell Lattitude E5570 w/ AMD Radeon R7 M370.

Below are the Radeon versions in case it helps us narrow this down.

Radeon Settings Version - 2017.0310.1611.29098 Driver Packaging Version - 16.60.2911-170310a-312047E-CrimsonReLive Provider - Advanced Micro Devices, Inc. 2D Driver Version - 8.1.1.1591 Direct3D® Version - 9.14.10.01249 OpenGL® Version - 6.14.10.13469 OpenCL™ Version - 21.19.525.0 AMD Mantle Version - 9.1.10.0179 AMD Mantle API Version - 102400 AMD Audio Driver Version - Not Available Vulkan™ Driver Version - 1.4.1 Vulkan™ API Version - 1.0.37

[thedbexp]

Tried that this morning -- you're right, just opening the Radeon Settings GUI makes the bash prompt load immediately. I didn't even have to click on anything in the GUI, I just opened it and then clicked on the bash prompt window and the shell appeared immediately.

My Radeon settings on a Lenovo E550 w/ Radeon R7 M265 :

Radeon Settings Version - 2017.0210.908.16431 Driver Packaging Version - 16.60.2011-170210a-311199C-ATI Provider - Advanced Micro Devices, Inc. 2D Driver Version - 8.1.1.1591 Direct3D® Version - 9.14.10.01249 OpenGL® Version - 6.14.10.13469 OpenCL™ Version - 21.19.519.2 AMD Mantle Version - 9.1.10.0179 AMD Mantle API Version - 102400 AMD Audio Driver Version - Not Available Vulkan™ Driver Version - 1.4.1 Vulkan™ API Version - 1.0.37

[whoisj]

The Radeon thing is likely the interaction between the new translucent console features and poorly written drivers (sorry, I used to work at NVIDIA and I relish picking on AMD :wink:).

Has anyone played with acceleration sliders or disabling the new console features?

[thedbexp]

The translucent console has been around for a while -- did something change in it recently to make it hardware accelerated or something? I've had my console transparency set up for years now and the slowdown only recently started happening (likely an AMD driver update) For the acceleration sliders -- you mean in the video driver? I also don't know what you mean by disabling the new console features. I tried turning off transparency in git bash, but that had no effect.

[trowpa]

I solved the Radeon/MinTTy issue (for me at least!).

After blaming AMD - and updating their driver (twice) hoping for a fix, i checked for an update to my onboard intel driver - and - indeed there was! I updated to the latest for my Intel 530 HD graphics and i'm back to normal!

For others that have this issue with Radeon - have you checked your onboard graphics driver?

[thedbexp]

Tried this. My laptop manufacturer appears to have put out a newer version of the Intel HD 5500 driver than Intel provides, so I couldn't install the Intel one using their exe package. I started to go through the motions of installing the Intel drivers manually -- I uninstalled the device and restarted. The AMD driver took over on reboot, but then my screen flickered right after rebooting and fixed its resolution.

Looking at it in the device manager, Windows reports that the AMD driver had an issue and has been disabled. So I have since uninstalled the AMD device from my system and for the moment, I am leaving it like that. My git-bash is functioning quickly again and there is nothing in particular I need the AMD driver for.

Incidentally, on reboot, Windows searched for and found an older driver build for the Intel HD 5500 graphics driver. The release date is 3 months earlier than the date on my last driver and the build number is smaller. If I've got time later, I might try to find the newer driver to see if the problem comes back. And at some point, I'll also want my Radeon to be functioning again. If any action results in my git-bash prompt becoming unusably slow again, I can report it back here if the thread is still open.

[dscho]

Thanks for all the reports. it seems that this ticket can be closed, then, as it is not Git for Windows' fault.

If any action results in my git-bash prompt becoming unusably slow again, I can report it back here if the thread is still open.

You can always comment on this ticket, even if it is closed, and everybody involved in the thread will still get the notifications.

[XeptionE]

I have a Win10 dell laptop with nvidia geforce MX130 and same problem with the slow git. Even a "cd" command requires ~2-3 Seconds to come back to git bash. Git version: 2.20.1.windows.1. My colleague has a similar laptop and no problems. Same git version.

The command "export PS1='$'" seams to eliminate the delay between command execution and showing prompt again. My problem is i use source-tree and have the issue with slow git there too.

[dscho]

@XeptionE maybe an anti-malware application on your system slows things down? As every year, I had to update to a newer code-signing certificate, and it is possible that certain anti-virus software trusts executables signed with the old one, but not with the new one.

[XeptionE]

@dscho I have checked my git installation and if i open windows command line and execute a git command, for example git status, it will print it immediately and return to bash immediately. if I use sourcetree and open the bash using sourcetree my git will be slow. same git, in two similar windows, different speed. my problem is, that sourcetree itself is slow too and I know it is git fault. Because of git is not slow in every window, i doubt my anti-malware is responsible for this kind of slowmotion problem.

[PhilipOakley]

If normal bash works fine, then surely it's Sourcetree that's not got it right.

If the problem persists, then a new Issue (rather than 'hijacking' an old issue) would be the way to go with a completed template and any extra information you have gleaned. You can refer back to this for context, by the versions have moved on. Significantly.