Git Bash in MinTTY ludicrously slow on Windows 10

[Nathan2055]

• I was not able to find an open
  or closed issue
  matching what I'm seeing

Setup

• Which version of Git for Windows are you using? 32-bit or 64-bit? Include the
  output of git version as well.

2.9.0.windows.1, 64-bit

• Which version of Windows are you running? 32-bit or 64-bit?

64-bit

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

Defaults, though I enabled support for Git from default cmd.exe (not the full Unix toolset, though)

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

I installed GitHub Desktop a few minutes before installing Git Bash, but uninstalled it because it was acting slow as well.

I also copied in a .gitconfig file as well as .ssh and .gnupg folders from my previous Windows install (Windows 7, I clean installed with 10 recently).

Details

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

Git Bash, AKA MinTTY

• 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.

Launching Git Bash

• What did you expect to occur after running these commands?

Git Bash to open

• What actually happened instead?

It sits on a black screen for a very long time, apparently executing "/usr/bin/bash --login -i". When it finally loads, running any Git command takes a very long time.

Git from within stock cmd.exe runs fine and fast.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

N/A

[dscho]

Please have a look here: https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues

[linquize]

Anti virus installed?

[Nathan2055]

@linquize - Yes, Trend Micro. I'll try adding an exception.

@dscho - Thanks, I'll test that and see if I can figure out what's causing the bottleneck.

[fourpastmidnight]

FWIW, I also use Trend Micro MaximumSecurity 2016 and I do not exclude the directory (or sub-directories) containing my local git repositories and I do not notice any performance issues. Also, I do not have core.fscache = true, so I should be running pretty slowly to begin with (I never got around to updating my configuration)--but the speed for me is acceptable in the repositories I work with.

I'm unclear, however, if you're working on a machine in a corporate environment (using Trend Micro OfficeScan, for example), where things could be impacted differently from that perspective. Definitely read through that Diagnosing Performance Issues wiki, it has some good stuff in there for helping track down what might be causing the issue--especially since its on startup of Git Bash.

[emahfoud]

I'm having exactly the same issue with Git 2.9 64bit. I also have Trend Micros Internet Security and while it was enabled, even the installer halted at 100%, and wouldn't finish until I disabled Trend. I kept all the default installation options.

Now starting Git Bash, or running any Git command takes several seconds whenever Trend is enabled.

I didn't not have this problem with Git 2.7.

[dscho]

@emahfoud any chance you can use the information in https://github.com/git-for-windows/git/wiki/Diagnosing-performance-issues to diagnose further?

[shytikov]

I have similar problems. Git v2 is so much slower than git v1. Using Windows 8/10 64 bit. Tried both git2 32 and 64 versions. Always ending up installing git1 and sticking with it. Otherwise very uncomfortable to work in command line interface.

Tried all optimizations. Just cannot get HOW c++ implantation could be slower than based on sh/perl and tcl...

Does anyone else has the same experience? How do you live this it? I'm ready do switch to fossil for personal use. It looks now it's faster than git...

[kostix]

@shytikov, supposedly because it spends time waiting on some resource rather than burning CPU cycles.

Say, it might be something like #193 (which I experienced even on Windows XP which usually does not have all these bizzare performance issues like Windows 8+ do).

[kostix]

@shytikov, as to Fossil, it's a nice DVCS with interesting ideas. But if you're used to staging, git $whatever --patch and rebasing, you'll quickly find it to be a toy system.

It's also has prettly horrible CLI interface: its web UI is awesome but if you want to not leave your console window for inspecting the history, your experience will be suboptimal at best.

(The community is nice and responsive but such is that of Git, too.) ;-)

[shytikov]

For me git is the best, but I need to do something with the speed. With v2 command line interface become uncomfortable even on newly created repositories!

[dscho]

@shytikov ranting does not fix the issue. If you are truly interested in fixing it, try to follow my earlier advice on diagnosing the slowness. Vague descriptions of some kind of perceived slow-down will achieve nothing good.

[shytikov]

@dscho, you're right. I'm working on proceeding with your earlier advice. And I will come back to you soon with more details.

So far I can share with you my other findings. It seems that cmder ships with portable version of git that on the same PC and with same configuration runs significantly faster! You can check my figures by following my link below:

cmderdev/cmder#1048

I don't know why difference is so dramatic! Once again, same PC, same cmd. Same user configuration file. I don't know what gives major part of the performance gain in this case...

[shytikov]

@dscho, unfortunately, nothing interesting in all these performance diagnostic steps.

I cannot tell where from that delay comes. I've tried to disable network drives, since have found when I move to office my home folder maps to network drive... Didn't helped at all.

Portable version delivered with Cmder started being slow for me. So I think it's something to do with my PC among other things.

But git1.9.5 works like lightning...

For example when I run gogs server on my local machine with git2 webpages with repository information opens with 12 seconds delay. When I switch to git1 delays about 0.1 second...

Do you have any vision WHY delays on Windows is encountered? Even for such a simple command as get git version, for example?

[shytikov]

Here is my simple test.cmd

@echo off
echo %time% < nul
git --version
echo %time% < nul

Here is results from git2 (with trace enabled):

16:07:37.68
16:07:38.279806 git.c:350               trace: built-in: git 'version'
git version 2.9.0.windows.1
16:07:38.28

Here is results from git1 (with trace enabled):

16:07:30.33
trace: built-in: git 'version'
git version 1.9.5.msysgit.1
16:07:30.35

Git1 is many times faster! And Git2 actually doing something before start actual task. You see, that version display took a very little time, but rest was just waiting for something.

Any ideas, what it could be?

[kostix]

@shytikov, you could try to somehow profile (I mean, with a suitable profiler application) your Git to try to figure out what and where is spending time.

As I've already mentioned, in the context of #193, even cat.exe bundled with GfW exhibited the offending behaviour, so may be you could start right there.

Now, if that would be a GNU/Linux- or *BSD-based platform, I'd reach for strace or the equivalent tool. AFAIK, there exist a 3rd-party tool for Windows which intercepts syscalls made by a process. So may be you could explore the matters there.

[kostix]

@shytikov, looks like it's doable with the stock MS tools.

[dscho]

Here is results from git2 (with trace enabled):

Just a quick guess: your home directory is on a network drive? If so, could you try again after setting the HOME environment variable to a local directory?

I do agree with @kostix that it makes tons of sense to use a real profile, though. Even something like ProcMon is often good enough to identify bottlenecks.

[shytikov]

Will be tracing git soon...

I was also thinking about network drive, but after I disconnected it — nothing changed. I also put my laptop into flight mode, results almost the same (trace was disabled):

18:27:54.09
git version 2.9.0.windows.1
18:27:54.81

18:27:48.05
git version 1.9.5.msysgit.1
18:27:48.08

I was setting HOME variable earlier, it had no effect, but I will try once again now.

[fourpastmidnight]

I can confirm that MinTTY is ridiculously slow. Unfortunately, I cannot pinpoint exactly when this slowness started occurring or whether or not it's directly related to Windows 10, MinTTY, or both.

My computer completely locked up on me yesterday, so I had to give it the "one-finger salute". Since I was forced to reboot (I usually hibernate every night), I decided it was time to install all the updates that were available since the last time I rebooted. This included the Windows 10 Anniversary Update. I also took the time to upgrade from Git for Windows 2.7.1 to the latest Git for Windows 2,9,3.

Some stats on my setup:

• Windows 10 Pro, x64 w/ Anniversary Update
• Git for Windows 2.9.3, x64
  • Used all the default options for installation
  • MinTTY is the console host
  • My home profile is located on the C: drive
  • All repositories being worked on are located on a local physical disk on the D: drive (i.e. not interacting over a network)
  • I have verified the same behavior when running Git for Windows under elevated privileges.

Now that I've upgraded from Git 2.7.1, I'm noticing this slowness that's being described. I haven't gone through diagnosing performance issues according to the linked-to Wiki articles as of yet. I plan on doing this later today. When I've run through that, I'll report on my findings. I just wanted to be able to confirm that something has changed with respect to Windows 10 and/or MinTTY that has in fact caused MinTTY to become much slower.

Please note that the slowness has nothing to do with Git in and of itself. It seems to be MinTTY that is slow (though I haven't ruled out that bash itself isn't the cause of the slowness, and not MinTTY). In other words, something between 2.7.1 and 2.9.3 has introduced slowness--but I have not had the time to determine the root cause. Also, when I went to close my Git for Windows session in MinTTY, by typing exit, the MinTTY console is just hanging there, with nothing in the console buffer, but it has not closed. And it's been about 10 minutes. Definitely something weird is going on here.

I began using Git for Windows 2.9.3 with a brand new Git repository, so the repository is very small, therefore, there shouldn't be a lot of overhead with any sort of "stat-ing" of the files. With v2.7.1, I did not have core.fscache set to true. I have decided to leave the default setting for v2.9.3--which is true.

UPDATE
I found that when I'm in a Git repository, the terminal responds much more slowly. I do have a custom prompt--and it ran just fine in v2.7.1 (though slower than the stock prompt), but with 2.9.3 it's much much slower than before. I will look into setting set -x in my etc/profile to diagnose any performance issues there.

UPDATE
OK, so the first time after installing Git for Windows 2.9.3 and running the MinTTY console host, and typing exit, MinTTY seemed to hang and would not exit. Upon restarting Git for Windows, typing exit in MinTTY resulted in the terminal exiting properly. The first time may have been a fluke.

UPDATE
I didn't notice any problems when running with set -x. I tried disabling core.fscache to see if that introduced slowness, but it's still just as slow. The next thing to try is removing my custom Git prompt and seeing if that's the main culprit (because my prompt is slow--something I've been meaning to fix but haven't gotten around to).

UPDATE
Removed my custom prompt to use the stock git-prompt. I have a single-file change in my new repository. I did a simple git diff command. Using the stock prompt, this command took approximately 3.5s to run (from the time I hit Enter to the time the prompt returned). Then I put my custom prompt back in place. The same command took approximately 5s. Now, my prompt was slower than the standard prompt. Previously, the standard prompt returned in about .25s while my prompt took about .5s - .75s (yes, it's slow, but didn't bother me so much that I looked into the performance issues as of yet). However, even 3.5s for the standard git prompt is unacceptable. So there's definitely something going on here. Again, none of this implies that it's Git, or Bash, or MinTTY--only that something has changed which is causing slowness. Is it Win10? Is it Win10 with AU? Is it MinTTY? I can't say.

CLARIFICATION of last UPDATE
So, when I said that it took about 3.5s to run the git diff command, I want to clarify that the diff operation in and of itself was really quick. It seems like most of the time taken by executing the command (in both the stock prompt and my custom prompt) is in redisplaying the prompt.

FOUND SOMETHING
OK, I've narrowed this down a bit. It turns out I wasn't using the stock Git prompt above--I had modified it slightly. Sorry about that. I have been able to determine, however, that it is most likely .bashrc-related. When trying to reinstate the original git-prompt that comes with Git for Windows, I ended up with a "black and white" only prompt. This prompt was blazing fast. Not sure if this is due to all color output being slow on MinTTY (said slowness being introduced somewhere between 2.7.1 and 2.9.0+--source of said slowness yet to be determined) or if it's specific to how the prompt is being constructed. Will keep reporting as I find things.

MORE INFO
OK, so I did manage to restore the default git-prompt that comes with Git for Windows and got it working correctly. It is blazing fast. So obviously, this means that something in my Bash profile is causing the massive slow-down. And it probably has something to do with my custom prompt implementation. It wasn't this slow in Git for Windows 2.7.1; but it's really slow now. For the OP of this issue, I would ask: Did you customize your Git prompt? This appears to be the cause of the slow down in my environment.

I do know that the standard git-prompt uses the [\e[mXX] sequences for outputting color. I've also read that this can cause issues with line wrapping in Bash. So my prompt uses various calls to tput to output terminal colors. Not sure if this is causing the performance issue or not--but obviously, I guess I'll be looking into that performance problem with my prompt now. 😉

[dscho]

@fourpastmidnight thanks for the thorough analysis! I look forward to see how it develops from here. For the record, my Git Bash here (Windows 10 + Anniversary Update) is fast.

[kostix]

@fourpastmidnight, executing programs on Windows always was known to be slow (slower than on a Linux-based system running on the same hardware) so yes, I'd try to stick with escape sequences to send ANSI colour controls to the terminal driver.

[shytikov]

I think it has something to do with the network... It's closest where I could get in my investigation.

Right now it works fine for me, and I haven't noticed what I've done to make it work.

But check do you have .gitconfig and .vimrc on network drive, if yes, can you copy them to local drive and try to restart? Maybe it's also SSH keys?

As I mentioned, I lost the track, but if you could do this accurately and get more information you will help guys to finally fix that problem.

[fourpastmidnight]

ANOTHER UPDATE
So, I'm running Git for Windows v2.9.2 x64 on my work computer. AND, I'm also using my custom git prompt on my work computer. I do not experience any slowness on this computer as I do on my home computer.

I am running Windows 7 Pro on my work computer, whereas my home computer is Win 10 Pro + AU. It doesn't appear that my prompt is the root issue of the slowness on my home computer afterall. (YAY! But it still is a bit slow for my liking, so one day I'm going to look into that. Thanks @kostix for the tip on using straight up ANSI terminal codes over tput.) So it is definitely something environmental--some difference between Windows 7 and Windows 10

@dscho: To be clear, I'm not saying that this issue has anything to do with the Win10 AU in particular, as this issue was filed months in advance of that update being available (however, that's not to say that @Nathan2055 isn't a Fast Ring Windows Insider, in which case, it could be Win10 AU-specific. @Nathan2055, are you a Fast Ring Windows Insider and did you have preview bits of the AU update installed when you filed this issue?) In order to rule out more possibilites, can you tell me @dscho, did you enable the Windows Subsystem for Linux feature of the Win 10 AU? That's one thing I enabled straight after installing this update.

[fourpastmidnight]

LAST UPDATE FOR NOW
So, I've needed to take some time to learn some stuff at home. As such, I've been using Git for Windows 2.9.3 on my home PC for a few days now as I commit changes to the project that's being used as the sample for what I'm learning. I don't know what's changed with my environment (as I haven't done anything explicit to help improve anything, I figured I'd just live with it for a while), but my prompt is now not as slow as it was when I first reported here. It's almost back to it's "normal" speed. In case you're wondering, I use a local GPO to disable Windows updates because they annoy me too frequently--I only reboot when I need to, and when I do, I install all required updates then. So no new Windows update has been installed that would've changed anything (at least, no update I'm aware of...:wink:).

Anyway, since this hasn't seen much other traffic since I posted my updates here and no response from @Nathan2055, I can't say that this is an "active" issue--for me anyway.

[fourpastmidnight]

I've been running Git For Windows 2.9.x on my home machine on Windows 10 Pro x64 w/ AU for a few months now. I experienced slowness initially after the installation--but it mysteriously went away a day later. I haven't heard anything back from anyone on this issue about whether or not they are still experiencing the sluggishness I also initially experienced, or whether or not they've tried going through the Diagnosing Performance Issues wiki page, especially from the OP.

In light of that, I'm closing this issue. If anyone can definitively show that Git for Windows v2.9+ is actually and significantly slower than it's predecessors, please reopen this issue with the evidence.

[ToMakeSense]

Found a workaround in here Solution to Git Bash is very slow in Windows!, it works!

git config --global core.preloadindex true  
git config --global core.fscache true  
git config --global gc.auto 256  

[linquize]

How do preloadindex and fscache relate to mintty?

[elieux]

How do preloadindex and fscache relate to mintty?

In that for most people MinTTY equals Bash equals Git prompt. When every command in the shell is followed by a delay from executing PS1, it's easy to misdiagnose what's actually slow. I assume this is the case.