Stefan Fuhrmann wrote on Sun, Jan 06, 2013 at 15:51:16 +0100: > On Sun, Jan 6, 2013 at 3:10 PM, Daniel Shahaf <danie...@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...
