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 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.

-- 
Johan