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

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

All is on local disk and system is idle.

Indeed, after gc the times went down:
10s -> 2.3s (subdirectory)
17s -> 9.5s (whole repo)

2 seconds is much better and I'd say acceptable for me. But my questions are:

Obviously these answers didn't come from any deep analysis, but are
educated guesses from me based on previous performance patterns we've
seen on the list:

- why is it so slow with not packed repo?

Your numbers show that you're I/O-bound:

quoted

quoted

$ time git status    > /dev/null
real    0m41.670s
user    0m0.980s
sys     0m2.908s

$ time git status -- src/.../somedir   > /dev/null
real    0m17.380s
user    0m0.748s
sys     0m0.328s

which is not surprising, since you said you dropped caches before-hand.
Repacking probably reduced your disk footprint by a lot, which meant
less I/O.

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

$ 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?  Usually that would not be the case on a
warm cache. If it is, then it sounds like you are short on memory to
actually hold the directory tree and object db in cache. If not, what do
the warm cache numbers look like?

- can it be faster without repacking?

Not really. You're showing an I/O problem, and repacking is git's way of
reducing I/O.

- even with packed repo, the time on small subdirectory is much higher
than I'd expect given time on whole repo and subdirectory size - why?

Hard to say without profiling.  It may be that we reduced the object db
lookups, saving some time, but still end up stat()ing the whole tree.
The optimization to stat only the directories of interest was in 688cd6d
(status: only touch path we may need to check, 2010-01-14), which went
into v1.7.0. What version of git are you using?

-Peff