Re: git status: small difference between stating whole repository and small subdirectory

Piotr Krukowiecki [off-list ref] writes:

On Wed, Feb 15, 2012 at 8:03 PM, Jeff King [off-list ref] wrote:

quoted

On Wed, Feb 15, 2012 at 09:57:29AM +0100, Piotr Krukowiecki wrote:

quoted

I notice that you're still I/O bound even after the repack:

quoted

$ time git status  -- .
real    0m2.503s
user    0m0.160s
sys     0m0.096s

$ time git status
real    0m9.663s
user    0m0.232s
sys     0m0.556s

Did you drop caches here, too?

Yes I did - with cache the status takes something like 0.1-0.3s on whole repo.

So umm, I'm not sure that leaves anything to be improved.

I looked at some strace dumps, and limiting the status to a subdirectory
(in my case, '-- t' in git.git) does omit the lstat()s on uninteresting
parts of the index-listed files, as well as the getdents() (i.e.,
readdir()) for parts of the tree that are not interesting.

BTW, some other parts of git-status's display may be responsible for the
amount of data it pulls from disk.  In particular, the "Your branch is
ahead" display requires computing the merge-base between HEAD and
@{upstream}.  If your @{upstream} is way ahead/behind, or points at a
disjoint chunk of history, this may mean essentially pulling all of the
involved history from disk.  If my memory of pack organization serves
right, the commit objects involved would essentially be spread across
the whole pack (corresponding to "time") and thus this operation would
more or less load the entire pack from disk.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch