Re: Progress report on git-blame

[David Kastrup]

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
address@hidden:/usr/local/tmp/emacs$ 

But it's obvious that significant further improvements will depend on
either or both
a) making git-blame respond to interactively determined requirements
(basically, reacting to expose events)
b) significantly decreasing the involved system time by employing a good
caching strategy
c) not letting the basic algorithm and the cached data progress
independently but try catering the workload order on what happens to be
in-memory at a given point of time.

c) is a very shady approach and would make debugging a nightmare.

At any rate, the user time already dropped by more than a factor of 4,
and I have not touched the inner work horse (the diff algorithm) at all,
just eliminated all the thrashing around it.  Now the diff algorithm
itself is a separate library by a separate author, with widespread use.
It would be rather optimistic to assume that there are significantly
low-hanging fruit to be found there.

Shrug.  I'll go see how I can reimplement the now defunct copy/move
detection not exercised without specific command line options in order
to get the current work into a shape where upstream can consider
accepting it.

-- 
David Kastrup