Re: git status takes 30 seconds on Windows 7. Why?

[John Keeping <john@keeping.me.uk>]

On Wed, Mar 27, 2013 at 01:15:43PM -0500, Jim Kinsman wrote:
> The only anti-virus I have installed is Microsoft Security Essentials
> I turned off and it was still the same:
> $ cat /usr/bin/gitstatus
> start_time=`date +%s`
> git status && echo run time is $(expr `date +%s` - $start_time) s
> 
> 
> $ gitstatus
> # On branch test
> # Changes not staged for commit:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #       modified:   orgoptions.php
> #       modified:   update_import_contacts.php
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> run time is 10 s

That doesn't seem hugely surprising to me.  I have a moderately sized
repository (3047 files, although it's Java so there are some deep trees)
and I get the following (Vista on a reasonably old laptop, best of 3,
Git version 1.8.1.msysgit.1):

$ time git ls-files >/dev/null

real	0m0.047s
user	0m0.015s
sys	0m0.015s

$ time git status >/dev/null

real	0m2.715s
user	0m0.000s
sys	0m0.031s


I'm not sure the "user" and "sys" times are correct, but the "real"
times feel right.  By comparison, on Linux on a much newer machine (so
not much of a comparison) on the same repository:

$ time git status >/dev/null

real	0m0.347s
user	0m0.171s
sys	0m0.167s


I think the simple reality is that Git was written with the assumption
that stat is cheap and that isn't really the case on Windows, where the
filesystem cache doesn't seem to do that well with this.  It may be that
Git's Windows compatibility code could do be made more efficient but I
know nothing about that, although a quick look in compat/mingw.c
indicates that Git does already use its own stat implementations in
place of the MSys ones in search of speed.


John