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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html