Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> writes:
> On Wed, Feb 15, 2012 at 8:03 PM, Jeff King <peff@xxxxxxxx> wrote:
>> On Wed, Feb 15, 2012 at 09:57:29AM +0100, Piotr Krukowiecki wrote:
>>>
>> 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?
>
> 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
--
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