3

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?

Improve this question
10
  • 1
    How 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?
    – grawity_u1686
    Commented May 21, 2019 at 14:27
  • 1
    If 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
    Commented May 21, 2019 at 14:29
  • @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
    Commented May 21, 2019 at 15:10
  • 1
    Is the index file also similarly large on your coworkers' systems, and/or on a freshly cloned repository?
    – grawity_u1686
    Commented May 21, 2019 at 15:12
  • 1
    Cool, 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
    Commented May 21, 2019 at 16:44

1 Answer 1

Reset to default
4
+50

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .