[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Progress report on git-blame
From: |
David Kastrup |
Subject: |
Re: Progress report on git-blame |
Date: |
Thu, 20 Feb 2014 19:33:57 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
David Kastrup <address@hidden> writes:
> David Kastrup <address@hidden> writes:
>
>> martin rudalics <address@hidden> writes:
>>
>>>> Well, I finally did "git gc --aggressive" on my Emacs repository and
>>>> tried again git-blame src/xdisp.c and the times got considerably _worse_
>>>> than before the packing (though the repository went to about a quarter
>>>> in size). So after my fixes the run time in real use cases is probably
>>>> dominated by unpacking the various revisions, particularly with a
>>>> well-compressed repository.
>>>
>>> Seems like the second law of thermodynamics still applies ...
>>
>> Yes, life is still easiest on the peanut galleries.
>
> At any rate, I forgot to set the comparison function on the governing
> priority queue, turning it into a FIFO. So the actual numbers on the
> packed repository are not as disappointing as I first thought.
>
> Here are the numbers, first the system version, then my own version:
>
> address@hidden:/usr/local/tmp/emacs$ time git blame HEAD src/xdisp.c
> >/tmp/blame1
>
> real 3m17.437s
> user 2m23.676s
> sys 0m52.560s
> address@hidden:/usr/local/tmp/emacs$ time ../git/git blame HEAD src/xdisp.c
> >/tmp/blame2
>
> real 1m24.628s
> user 0m32.008s
> sys 0m52.044s
> address@hidden:/usr/local/tmp/emacs$ cmp /tmp/blame1 /tmp/blame2
Aaaand one can shave off about 50 seconds from either by doing
git config --add core.deltaBaseCacheLimit 128m
(assuming that one has more than about 512mb of main memory, of course).
Which gets us to
address@hidden:/usr/local/tmp/emacs$ time git blame src/xdisp.c >/dev/null
real 2m26.690s
user 2m12.148s
sys 0m13.772s
for the current Git code, and
address@hidden:/usr/local/tmp/emacs$ time ../git/git blame src/xdisp.c
>/dev/null
real 0m27.519s
user 0m20.248s
sys 0m7.156s
for my version of git blame. So once one has bumped
core.deltaBaseCacheLimit to a value where Git is not constantly stepping
on its own feet with a heavily packed repository, the changed blame
program will buy a further factor of 5.
At any rate, there is no point in _not_ saving the 50 seconds for
bumping the deltaBaseCacheLimit right now. Certainly _iff_ you did
git gc --aggressive and thus got a ridiculously expensive to unpack
repository.
--
David Kastrup
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Progress report on git-blame,
David Kastrup <=