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