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: >>> $ 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 -- 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