On Fri, 2005-09-23 at 07:40 -0400, C. Michael Pilato wrote:
> kfogel@collab.net writes:
>
> > "Peter N. Lundblad" <peter@famlundblad.se> writes:
> > > HOw about the remaining blame optimizations (dberlin?)? I'm talking about
> > > the reversal of the revision fetching.
> >
> > I recall hearing that DannyB had done some tests and decided that the
> > speedup wouldn't be enough to justify the extra complexity introduced
> > by this change, especially after #1970 got done.
> >
> > DannyB will, I hope, correct me if I'm misremembering...
>
> Adding DannyB to the To: line, just in case...
>
> I, too, am interested in the relationship between the blame speedups
> and issue #1970. Besides the obvious improvement of the initial
> get-locations call that precedes the real annotation work,
At least for GCC, this was where most of the slowdown was.
For files like ChangeLog, which had 50k revisions, it spent 10-20
minutes doing the get-locations and 3 minutes doing the blame. It would
send nothing during get-locations, and was not ctrl-c'able.
Reverse blaming sped this up in part because it was streamy (IE it would
send during get-locations), so the times of doing blame vs get-locations
overlapped, causing a speedup. It was also more responsive.
It was also just faster, which gave you about a 15% speedup in blaming
on most files.
Other than that, the only case the new blame will *really* help is if
your files can be blamed in less than the number of revisions you've
asked for (ChangeLog could). This requires a nice way to tell the
server you are finished blaming before it's finished sending revisions.
Considering all the algorithmic complexity, etc, it seemed hardly worth
it at that point for a 15% speedup. 3 minutes vs 2 minutes 45 seconds
is not interesting :).
Both blame algorithms are diff bound, and there are some obvious
hotspots in diff (IE things that profiling shows taking >30% of the
time). Thus, IMHO, it makes a lot more sense to work on diff's speed
now that 1970 is fixed, than introduce a lot of complex code for a 15%
speedup on blaming most files.
All of this is why i stopped working on blame once patches for 1970
started becoming available (IE when Greg attached his first closest copy
patch that only worked on FSFS). It reduced the blame time for files on
gcc that have been around a while from 15-25 minutes to 2 or 3.
> I don't see
> how #1970's fix is of use to the blame code at all.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 14:51:46 2005