Stefan Fuhrmann wrote on Sun, Jan 06, 2013 at 15:51:16 +0100:
> On Sun, Jan 6, 2013 at 3:10 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > Branko Čibej wrote on Sun, Jan 06, 2013 at 11:27:09 +0100:
> > > Caching is part of the FSFS backend. One would assume that a key-value
> > > database like BDB would have its own cache, which is therefore
> > > implicitly part of the BDB back-end. I don't see how you could construe
> > > these numbers as skewed.
> >
> > Just look at all the different svn_cache__t instances in FSFS. They
> > include, for example, a cache of combined svndiff windows --- that's not
> > something the db layer is going to have.
> >
>
> While that is true, there plenty of algorithmic improvements
> have been made to the FSFS code as well. I just re-ran one
> of the benchmarks with a completely default svnserve
> configuration (16M cache, no fulltext, txdelta nor revprop
> caching). Results:
>
> (1): (2) : (3)
> 1 : 6.8 : 5.0 svn-bench null-log ^/trunk -v -g
> 1 : 15 : 5.8 (second run)
>
> The missing delta and revprop caches hurt the space-optimized
> FSFS configuration (3) much more than FSFS defaults.
This comparison is still unfair since (3) compresses dir reps but (1),
I think, doesn't but could. Which points out that when we next rewrite
the FS library, we should re-draw the link between libsvn_fs and
libsvn_fs_foo --- in a manner that avoids us having to implement all
these little features for each backend separately...
Received on 2013-01-07 12:48:05 CET