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 00:45:19 CEST