Re: Progress report on git-blame

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sat, 25 Jan 2014 02:06:43 +0100
>> 
>> 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.
>
> Thank you for doing this.

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.  The positive thing about it is that fixing
the blame algorithm will make the remaining culprits stand out more
prominently when profiling.

The downside, of course, is that I had not been banking on having to
rework more than the blame algorithm itself to move C-x v g into the
"tolerable" area.

[system version]
dak@lola:/usr/local/tmp/emacs$ time git blame src/xdisp.c >/dev/null

real	3m5.786s
user	2m21.168s
sys	0m43.956s

[my version]
dak@lola:/usr/local/tmp/emacs$ time ../git/git blame src/xdisp.c >/dev/null

real	2m11.865s
user	1m13.372s
sys	0m57.656s

I am currently using commit time for prioritizing a breadth-first search
exhausting all later commits before going to previous revisions.  That
may result in worse object retainment patterns for the unpacking stage
while walking backwards in history.


Apart from trying to bully up general git performance and from trying to
get the unpacking to cache smarter, it would also be feasible to add a
"fast track" interface to git blame --interactive where Emacs sends
information about "currently viewed material corresponds to lines
xxx...yyy in the file" to the running git process which is used for
prioritizing the outstanding work.  That would be reasonably doable from
the git side, but of course it would require additional support from
vc-git.

I did that kind of thing in preview-latex (an in-document viewing mode
available in AUCTeX) for being able to work with large files and
four-figure amounts of included graphics while rendering all the
graphics with GhostScript on a 200MHz CPU.  It has sort of an
xroach-like effect where everything looks calm and finished until you
try scrolling around in the document.

While that stuff does not help with non-interactive use like M-x occur,
it should be useful even for incremental search as long as the search
concerns the _meat_ of the lines rather than the blame info.

But I definitely don't have the time to work on the Emacs component of
that sort of thing myself.

-- 
David Kastrup