git status is really slow only on one computer

0

Our organization has about a dozen developers with the same model of computer in their workstation (Dell XPS 15 9570), all running Windows 10. We work from a large-ish git repo (about 60,000 files, 10 GB).

On everyone's computer except mine, running git status in git bash takes about 300 ms. On my computer it takes about 1600 ms:

$ time git status
...
real    0m1.592s
user    0m0.000s
sys     0m0.015s

I ran winsat disk -drive c on my computer and compared the results to a few others around me, but there wasn't any significant variance across the results.

Running in Safe Mode brings it down to about 1100 ms. Running as administrator doesn't make a difference. Running in different terminals (cmd, cmder) doesn't make a difference. None of us use sparse checkouts. git gc doesn't make a difference. All of us have the latest updates, firmware, etc. for our machines.

What can I do to bring myself to parity with the other computers? I know I can tweak git status to only look in certain folders to reduce the time to almost nothing, but I'm looking to find the root cause of the time difference. Is there a specific thing I should be measuring or benchmarking to try narrowing down the cause of my slowdown?

Jeff E

Posted 2019-05-17T16:32:27.067

Reputation: 906

1How long does dir /s > nul or find -ls > /dev/null take, out of curiosity? Are you using native Windows Git (msysgit) or Cygwin Git or WSL Git? How large is your .git/index file? Do you have any differences in git config -l from your coworkers? Do you have any smudge/clean filters configured? – user1686 – 2019-05-21T14:27:20.203

1If you clone the directory anew (git clone ssh/https-location foldername), is the behavior the same? You can get a local git repo into a messed up state from which recovery is difficult, so it would be good to know if this is a problem with your machine or the specific copy of the repo you have. – aggieNick02 – 2019-05-21T14:29:20.910

@grawity: dir /s > nul takes 2300 ms. My git --version is 2.19.1.windows.1. My .git/index is 8.1 MB. I don't have any smudge/clean filters. I'll check for differences in git config -l. – Jeff E – 2019-05-21T15:10:20.740

1Is the index file also similarly large on your coworkers' systems, and/or on a freshly cloned repository? – user1686 – 2019-05-21T15:12:39.400

@Biswapriyo: I've got an SSD, but in any case defrag c: /A shows 43% total fragmented space. – Jeff E – 2019-05-21T15:13:19.217

@grawity: it's 8.1 MB on coworkers' systems as well as a freshly cloned repo. – Jeff E – 2019-05-21T15:35:36.983

@aggieNick02: a new clone seems to be much faster, about 450 ms. I tried git clean -xdf on the original repo but that one is still slow. Now that I've got a fast clone, are there any differences I should check between the two? – Jeff E – 2019-05-21T15:36:42.290

Looks like fscache = false snuck into the slow repo's config. I took that out and it's nice and fast again. – Jeff E – 2019-05-21T15:45:50.247

1Cool, I'm glad it was something easy to change. I've had the files in the .git folder get messed up enough that it was easier to just start anew. I'm guessing that fscache was set in .git/config ? – aggieNick02 – 2019-05-21T16:44:10.740

@aggieNick02: As your idea solved the problem, you could write an answer. – harrymc – 2019-05-22T06:08:55.737

Answers

1

The first thing to determine is if the poor behavior is due to your machine or to your specific local copy of the repo. The files in your .git folder can affect performance in various ways - settings in .git/config, presence of lfs files, commits that can be garbage collected, etc.

If it is the local copy of the repo at fault, then you can dig into what is different - checking .git/config first is probably a good idea.

Or if all of your changes are committed and both repos have the same commit history (point to the same HEAD), then you can even delete the bad .git and replace with the good. If you have changes not committed or the repos have different commit histories, this is a bad idea, and you'll lose work and/or confuse Git.

If it is something about your PC, then you have to start asking what is different between your PC and everyone else's. That can be a number of things (software or hardware), but comparing file access logs/timings via sysinternals or procmon while running git status would probably be a good start.

aggieNick02

Posted 2019-05-17T16:32:27.067

Reputation: 224