in reply to Re^2: Threaded Code Not Faster Than Non-Threaded -- Why? (meat)
in thread Threaded Code Not Faster Than Non-Threaded -- Why?
I think you're misreading it - it includes examples of creating queues, but I don't see it implying that you need multiple queues.
I have an example of a 'queue based' worker thread model: A basic 'worker' threading model
Personally I'd be thinking in terms of using 'File::Find' to traverse your filesystem linearly, but have if feed a queue with files that need more detailed inspection. The two most expensive operations in this process are: Filesystem traversal (which is hard to optimise without messing with disks and filesystem layout). Also - reading the files for calculating their hashes - the reading of files may well be more 'expensive' than doing the sums. My thought would be to ask if you can do partial hashes, iteratively - if you work through a file say 'one block' at a time (varies depending on filesystem) you have a single read IO operation, that you then hash - and can work through a file if it's longer, until hashes don't match. If the file is a genuine dupe, then you'll still have to read the whole lot, but if it's not it'll discard faster.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: Threaded Code Not Faster Than Non-Threaded -- Why? (meat)
by Tommy (Chaplain) on Jan 05, 2014 at 17:56 UTC | |
|
Re^4: Threaded Code Not Faster Than Non-Threaded -- Why? (meat)
by Tommy (Chaplain) on Jan 06, 2014 at 01:06 UTC |