[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Optimizing back-end: saving cycles or saving I/O (was: Re: [PATCH v2] Saving a few cycles, part 3/3)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 14 May 2010 01:45:05 +0200

On Wed, May 12, 2010 at 9:12 PM, Greg Hudson <ghudson_at_mit.edu> wrote:
> On Wed, 2010-05-12 at 13:44 -0400, Hyrum K. Wright wrote:
>> There may be other ways of caching this information, which would be great.
>
> Maybe.  Caches add complexity, and too many layers of caching (disk, OS,
> application) can actually reduce performance in some scenarios.
>
> I would suggest getting a better understanding of why this operation is
> slow.  Why is svn log opening each rev file ten times?  Is this
> intrinsically necessary?  Going straight to optimizing the overused
> low-level operations can provide a noticeable performance benefit, but
> fixing the inefficient high-level algorithms is how you can turn minutes
> into microseconds.

+1

I was actually investigating this for svn log (trying to correlate the
low-level operations with the high-level flow, trying to understand
the how and why). But being a newbie to the svn code base it wasn't
easy to get a grip on it. And then I got interrupted by other
priorities ...

Maybe I'll pick it up again one day, but if someone else (with more
inside knowledge?) wants to take a look as well ...

Concerning "some sort of caching": I agree that it adds complexity. I
was just hypothesizing that it might be very difficult to change the
high level algorithms/flow/... (e.g. because they depend on
interaction with the other layers in a certain way, a lot of
dependencies, ...). In that case it might just be easier to tackle the
problem at a lower level. But I guess we'll need to do the correct
analysis first, to find out why, before speculating any further ...

Cheers,

-- 
Johan
Received on 2010-05-14 01:45:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.