4x speedup of recursive rmdir in std.file

[Nick Sabalausky]

"Jay Norwood" <jayn at prismnet.com> wrote in message 
news:jgm5vh$hbe$1 at digitalmars.com...
> == Quote from Nick Sabalausky (a at a.a)'s article
> > Interesting. How does it perform when just running on one core?
>
> The library without the threads is 1 min 5 secs for the 1.5GB
> directory structure with about 32k files.  This is on an 510
> series intel ssd.  The win7 os removes it in almost exactly the
> same time, and you can see from their task manager it is also
> being done single core and only a small percentage of cpu.  In
> contrast, all 8 threads in the task manager max out for a period
> when running this multi-thread remove. The regular file deletes
> are occurring in parallel.  A single thread removes the directory
> structure after waiting for all the regular files to be deleted by
> the parallel threads.  I attached a screen capture.
>

What I'm wondering is this:

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?

> I tried last night to do a similar thing with the unzip processing
> in std.zip, but the library code is written in such a way that the
> parallel threads would need to create the whole zip archive
> directory in order to process the elements.   I would hope to be
> able to solve this problem and provide a similar 4x speedup to the
> unzip of, for example 7zip, which is currently also showing
> execution on a single thread.  7zip takes about 50 seconds to
> unzip this file.
>

That would be cool.