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

Re: Case study: Mono switches to Subversion

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-11-18 02:25:41 CET

On Wed, Nov 17, 2004 at 09:18:00PM +0100, Marcin Kasperski wrote:
> > In svn 1.0, 'blame' was about 100x slower than CVS. In svn
> > 1.1, it's about 10x slower. I really can't think of any way
> > to make it faster, other than doing what CVS does: keeping a
> > cache of contextual diffs on the server, so the server can
> > instantly generate annotation.
> I know nothing about the subversion internals but what about
> generic speed-up technique - caching! First, if svn blame is

Caching is like patriotism; the last resort of a scoundrel. :-)

Seriously, though: the way the blame algorithm works, there's
really no good place to put the cache, other than where it
already is: in the server's kernel's filesystem cache.

> really run very often, there is good chance that someone calling
> it will find cached reply just sent to someone else, ready to
> use as no commit occured after it. Second, if there is cached
> result of svn blame blahblah.cxx at revision 17784, next svn
> blame blahblah.cxx comes and repo is at revision 17787, we have
> to analyze only diffs between 17784 and 17787 and apply them to
> the cached data.

This would work best if we calculated blame server side, which
we don't, currently. If we were to do so, it might make sense
to lazily and incrementally compute the blame information,
as you suggest, or (more simply) to simply always compute
it at commit time (as others have suggested).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 18 02:24:43 2004

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.