Re: Progress report on git-blame

[David Kastrup]

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