Progress report on git-blame (was: RFC - cleaning up /etc)

[David Kastrup]

David Kastrup <address@hidden> writes:

> Lars Magne Ingebrigtsen <address@hidden> writes:
>
>> a `C-x v g' that's so slow it's unusable (but David is fixing that),
>
> Will still take a year to trickle down to typical users.  Man, my fix
> better be good with everybody taking its efficacy for granted.

Taking the following test job:

#/bin/sh

cd /tmp
rm -rf testit
mkdir testit
cd testit
git init
for inc in 8 4 3 7 2 9 5 6 1
do
    seq 252000 -$inc 0 > testfile
    git add testfile
    git commit -m "Run with increment $inc"
done
time git blame testfile >/dev/null

my current code (which is not ready for submission as it does not
support all options of git-blame yet) takes 2 seconds for the git-blame
step as opposed to the 40 seconds the system binary does.  That's at
least encouraging and one can expect some of that to be pure output
time.

For blaming src/xdisp.c, however, it only drops the execution time from
3:00 minutes to about half.  30 seconds of that is system time, and it
is basically identical to before.

So while I have made good progress on the "lots of tiny changes"
behavior, the "so slow it's unusable" angle for real-world files will
likely require meddling with when and how and why I/O is being done (or
conceivably memory allocation/deallocation).  And in that area, I've not
yet done or even profiled anything, so I have no clue how much can be
done.  It's possible that repository repacking could help independently.

At least having gotten the linear list operation thrashing out of the
way will help with further profiling.

Of course, the actual output is identical (or a progress report would
not have made much sense).  Top memory usage also is very much the same
(about 340MB for blaming src/xdisp.c).

-- 
David Kastrup