I've been looking at which bugs can be closed by the pending
completion of wc-ng. In particular, I've been looking at issue #1284:
http://subversion.tigris.org/issues/show_bug.cgi?id=1284
The issue is essentially a complaint about the performance of 'svn mv
somedir targetdir' when the number of files in somedir is very large,
in the thousands. It's a performance bug with no real good feeling
for done, but given the performance improvements of wc-ng, I'm marking
it as so.
What I thought people would be interested in are the actual numbers I
used to justify the bug closure. Although I narrow use case, I think
this provides an interesting window into wc-ng. The script used to
generate these results is attached to the issue:
http://subversion.tigris.org/nonav/issues/showattachment.cgi/1156/test.sh
The script runs the experiment for a given number of trials for
several directory sizes, on both trunk and 1.6.x. I also ran it on a
couple of different machines: my OS X laptop, which has a relatively
slow disk, and a Linux box with a relatively speedy disk. The
following numbers are all arithmetic means over the various trials for
a given scenario. Times are in seconds. (Standard deviations within
each scenario were all relatively small.)
Slow Disk
=========
Files | 1.6.x Trunk | Improvement
--------+----------------------+---------------
10 | 0.98 0.97 | -
100 | 0.97 0.98 | -
1000 | 17.92 9.16 | 48.9%
5000 | 440.92 75.71 | 82.9%
Fast Disk
=========
Files | 1.6.x Trunk | Improvement
--------+----------------------+-------------
10 | 0.07 0.10 | -
100 | 0.33 0.19 | 42.4%
1000 | 18.31 2.23 | 87.8%
5000 | 322.10 34.08 | 89.4%
I haven't run any higher statistical analysis on these, but the raw
numbers are compelling. For both fast and slow disks, wc-ng speeds up
this particular operation by *a lot*, and the difference increases as
the number of files. I suspect the same may be true for other
disk-intensive activities in a single directory.
Another observation is that the trunk times for the fast disk are much
different than those of a slow disk, but I'm not really sure what to
divine into that (the boxes also have different CPU speeds, cache
sizes, etc.)
Still interesting stuff, though.
-Hyrum
Received on 2011-01-18 00:33:35 CET