Hey Stefan... forgive my terseness: on phone while camping...
Wanted to respond to your initial paragraph. The WC still has a large schema
change ahead. However, I do not think it will significantly alter your
analysis. I believe there are more non-schema effects in play here.
Cheers,
-g
On Sep 5, 2010 6:45 PM, "Stefan Fuhrmann" <stefanfuhrmann_at_alice-dsl.de>
wrote:
> Hi all,
>
> Now that the WC format is in its final state, I want
> to throw in some of my measurements as well.
>
> You are probably aware of most of the issues already,
> for instance running 15 SQL parametrized queries per
> node instead of 3 to 5 per folder. To beat the 0.13s
> that st needs in 1.6 for the TSVN source (6800 nodes),
> you would need to execute each statement in less than
> 1.3usecs.
>
> But one would consider these numbers "fast enough".
> Therefore, I ran some larger tests and the results
> are as expected and not not all are bad:
>
> (1) KDE trunk via svn://localhost 400,000 node wc
> on a very slow external USB disk (80GB EXT4).
> This is mostly uncached I/O.
>
> co 1.6.9 1.7
> real 26m9.422s 20m19.980s
> user 4m43.342s 6m18.024s
> sys 3m44.718s 5m28.981s
>
> disk[kB] 21,490,448 18,757,472
>
> st
> real 1m2.887s 1m7.290s
> user 0m6.660s 0m37.126s
> sys 0m3.800s 0m20.649s
>
> up
> real 2m41.151s 0m46.895s
> user 0m4.076s 0m25.266s
> sys 0m2.936s 0m10.885s
>
> So, the physical I/O gets reduced in 1.7 and the
> effect is clearly visible. Design goal reached.
> As a bonus, about 10% of disk space can be saved.
>
> But one also can see that CPU load is much higher
> (5+ times) and it will become an issue once I/O
> caching is in effect.
>
>
> (2) KDE trunk core sources (trunk/KDE) via svn://localhost
> 81,500 node wc on a RAM disk (tmpfs).
>
> co 1.6.9 1.7
> real 1m13.303s 1m55.934s
> user 0m42.559s 1m5.380s
> sys 0m30.618s 0m50.255s
>
> disk[kB] 1,986,816 1,789,364
>
> st
> real 0m1.257s 0m11.563s
> user 0m0.872s 0m7.268s
> sys 0m0.364s 0m4.276s
>
> up
> real 0m0.823s 0m7.435s
> user 0m0.560s 0m5.236s
> sys 0m0.268s 0m2.152s
>
> For cached wcs, I consistently get proportionally
> similar data showing SVN 1.7 to be 6 (small wcs)
> to 9 times (large wcs) slower than 1.6 - depending
> on the wc size (there seems to be a constant part
> just for opening a wc).
>
> Personally, I care most about the second case since we
> have quite large wcs at the office whose management
> information can still be cached properly.
>
> Just my EUR 0.02 ;)
>
> -- Stefan^2.
>
Received on 2010-09-06 03:20:52 CEST