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" <stefanfuhrm...@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. >
