Re: svn commit: r1445973 - in /subversion/trunk/subversion: include/svn_ra.h include/svn_repos.h libsvn_repos/rev_hunt.c tests/libsvn_repos/repos-test.c

On Thu, Feb 14, 2013 at 3:44 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
>> Sent: donderdag 14 februari 2013 15:10
>> To: Johan Corveleyn
>> Cc: Bert Huijben; Bert Huijben; dev_at_subversion.apache.org
>> Subject: Re: svn commit: r1445973 - in /subversion/trunk/subversion:
>> include/svn_ra.h include/svn_repos.h libsvn_repos/rev_hunt.c
>> tests/libsvn_repos/repos-test.c
>>
>> On 02/14/2013 04:04 AM, Johan Corveleyn wrote:
>> > On Thu, Feb 14, 2013 at 1:20 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> >> We currently fetch all the revision numbers (inserted in an array in the
>> >> wrong order.. which we then reverse) and then start delivering changes.
>> >>
>> >> I would be surprised if the revision/path walk step would make a huge
>> >> difference compared to delivering the actual changes (We now always do
>> that
>> >> before the first revision, so it is not slower than the current server side
>> >> algorithm). But if it is we can optimize it later.
>> >
>> > I'm pretty sure this can make a big difference if you're blaming files
>> > with a long history. I'm talking about files with a couple thousand
>> > revisions, which date back to, say, r100, and run up to r200,000. If
>> > caches are cold (which usually is the case for those very old
>> > revisions), it can take minutes for the server to crawl history and
>> > collect all those revs. During those minutes, the client is just
>> > waiting, twiddling its thumbs, holding all of its CPU power ready for
>> > pulling the first revisions through its diff algorithm :-).
>> >
>> > But you're right of course, that this can be optimized later.
>>
>> On the plus side, at least Bert didn't introduce anything unique here --
>> 'svn log' does precisely the same thing when asked to produce logs from
>> OLDER_REV to NEWER_REV. (Still, I agree that the process isn't ideal.)
>
> I followed up with Johan using a Dutch private mail and he was interested in seeing the performance improvements.
>
> I applied these changes today, with an ra-capability exchange to allow choosing between implementations without waiting for an error.

Yay!

Although ... Bert tricked me into raising my hand for working on the
client part of the "backwards walking blame" :-).

Unless someone else does it first of course, hint hint (I'm pretty
slow, so that shouldn't be all that hard ;-).

-- 
Johan