4x speedup of recursive rmdir in std.file

[Jay Norwood]

== Quote from Andrei Alexandrescu
> > Suppose all the cores but one are already preoccupied with
other stuff, or
> > maybe you're even running on a single-core. Does the threading
add enough
> > overhead that it would actually go slower than the original
single-threaded
> > version?
> >
> > If not, then this would indeed be a fantastic improvement to
phobos.
> > Otherwise, I wonder how such a situation could be mitigated?
> There's a variety of ways, but the simplest approach is to pass a
> parameter to the function telling how many threads it's allowed
to
> spawn. Jay?
> Andrei

I can tell you that there are a couple of seconds improvement in
the execution time running 16 threads vs 8 on the i7 on the ssd
drive, so we aren't keeping all the cores busy with 8 threads. I
suppose they are all blocked waiting for file system operations
for some portion of time even with 8 threads.  I would guess that
even on a single core it would be an advantage to have multiple
threads available for the core to work on when it blocks waiting
for the fs operations.

The previous results were on an ssd drive.  I tried again on  a
Seagate sata3 7200rpm hard drive it took 2 minutes 12 sec to
delete the same layout using OS, and never used more than 10%
cpu.

The one thread configuration of the D program similarly used less
than 10% cpu but took only 1 minute 50 seconds to delete the same
layout.

Anything above 1 thread configuration on the sata drive began
degrading the D program performance when using the hard drive.
I'll have to scratch my head on this a while.  This is for an
optiplex 790, win7-64, using the board's sata for both the ssd and
the hd.

The extract of the zip using 7zip takes 1:55 on the seagate disk
drive, btw ... vs about 50 secs on the ssd.