Hi all, I ran a few tests to determine the impact of the missing revprop caching on trunk. For checkouts, the overhead is ~2 extra CPU cores per saturated 10Gb network. Even that will be not be severe issue to users and the changes mentioned below bring it down to .5 cores.
'svn log -v' is a factor of 2 slower for the http: client and 4x for the svn: client. Server load is approx 3x and 8x as high, respectively, if revprop caching is not available. Most of the overhead is spent parsing packed revprop manifest info. I wrote a series of patches that reduces the overhead such that the http: client will see no real difference while the svn: client takes only 50% longer than it would with a revprop caching server. These are only ballpark numbers run on a system with high bandwidths, low latencies and low fopen() overhead. However, I think we can tune the revprop file granularity and parsing now and defer the FSFS revprop caching to 1.10 without a massive impact on users. -- Stefan^2.
