Re: Progress report on git-blame

[David Kastrup <dak@gnu.org>]

David Kastrup <dak@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> martin rudalics <rudalics@gmx.at> 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:
>
> dak@lola:/usr/local/tmp/emacs$ time git blame HEAD src/xdisp.c >/tmp/blame1
>
> real	3m17.437s
> user	2m23.676s
> sys	0m52.560s
> dak@lola:/usr/local/tmp/emacs$ time ../git/git blame HEAD src/xdisp.c >/tmp/blame2
>
> real	1m24.628s
> user	0m32.008s
> sys	0m52.044s
> dak@lola:/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
dak@lola:/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

dak@lola:/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