On Thu, Feb 16, 2012 at 3:05 PM, Thomas Rast <trast@xxxxxxxxxxx> wrote:
> 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.
But even with caches time on small directory is only half of time on whole repo:
0.15s vs 0.07s
> 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.
Same in my case.
I've run strace with -c which shows system calls times. As I
understand the results the time used by lstat() is very small. With
dropped caches:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
90.70 0.065108 3 25361 12 lstat
6.78 0.004869 1 6534 getdents
1.94 0.001392 0 6964 3238 open
0.27 0.000194 0 3726 close
> 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.
I don't think this is the case - I'm using git-svn and thus have no
upstream in git meaning.
--
Piotr Krukowiecki
--
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