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?
1How long does
dir /s > nul
orfind -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 ingit config -l
from your coworkers? Do you have any smudge/clean filters configured? – user1686 – 2019-05-21T14:27:20.2031If 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. Mygit --version
is2.19.1.windows.1
. My.git/index
is 8.1 MB. I don't have any smudge/clean filters. I'll check for differences ingit config -l
. – Jeff E – 2019-05-21T15:10:20.7401Is 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.290Looks 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.2471Cool, 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