It seems like it will take a bit of experimentation to figure out how long to sleep and how deep to keep the queue.

These are not as critical as you might first think.

1. sleep: A thread that calls $Q->pending once every millisecond will consume so few cycles that it barely registers on taskmanager/top.

   Try this:

   perl -MThread::Queue -E"$Q=new Thread::Queue; $Q->pending while Win32:
   +:Sleep( 1 )"
   [download]

   On my system, that shows up in Process Manager as 0.0%.

   So, running it at a frequency of once every timeslice -- ~10 milliseconds -- will consume negligible cpu whilst ensuring that the queue is (re)populated in a timely manner.

2. Queue Length: A queue, shared between 16 threads, populated with a million longish paths, will consume less than 200MB.

   Try:

   perl -Mthreads -MThread::Queue -E"async{ sleep }->detach for 1 .. 16; 
   +$Q=new Thread::Queue; $Q->enqueue( qq[/a/longish/path/and/filename$_]
   + ) for 1 .. 1e6; sleep;"
   [download]

   Which given a typical modern system with 4-16 GB is nothing to concern ourselves with; and is at least 3 order of magnitude greater than I'd recommend as a starting point (100 for 16 threads).

For IO-bound process like this, tuning either or both variables over quiet a large range of values will have little or no effect on overall throughput.