Re^2: Parallel::Forkmanager and large hash, running out of memory

I wish it were that simple...unfortunately, the needed lookup values are distributed across a couple thousand files and it is not possible to predict which file it will be found in...

As-is, I am running the code in parallel using Parallel::Forkmanager, which seems to be working just fine...as long as I don't run out of memory ;-)

Comment on Re^2: Parallel::Forkmanager and large hash, running out of memory

Replies are listed 'Best First'.
Re^3: Parallel::Forkmanager and large hash, running out of memory by locked_user sundialsvc4 (Abbot) on Apr 25, 2013 at 13:05 UTC
A problem like that one could be handled by scanning all the files ahead of time and pushing the lookup values into a database table. This would avoid the need to “look for” the answers you want, which could largely defeat your efforts at parallelization. A pre-scanner could loop through the directory, query to see if it has seen this particular file before, and if not, grab the lookups and store them. Each time, it would only consider new files. (In the database table, you could also note whether a particular file had already been processed. Something like an SHA1 hash could be used to recognize changes.) This, once again, could be used to reduce the problem to a single-process handler that can be run in parallel with itself on the same and/or different systems. By all means, if you have now hit-upon a procedure that works, I am not suggesting that you rewrite it.

Replies are listed 'Best First'.

Re^3: Parallel::Forkmanager and large hash, running out of memory
by locked_user sundialsvc4 (Abbot) on Apr 25, 2013 at 13:05 UTC

A problem like that one could be handled by scanning all the files ahead of time and pushing the lookup values into a database table. This would avoid the need to “look for” the answers you want, which could largely defeat your efforts at parallelization. A pre-scanner could loop through the directory, query to see if it has seen this particular file before, and if not, grab the lookups and store them. Each time, it would only consider new files. (In the database table, you could also note whether a particular file had already been processed. Something like an SHA1 hash could be used to recognize changes.)

This, once again, could be used to reduce the problem to a single-process handler that can be run in parallel with itself on the same and/or different systems.

By all means, if you have now hit-upon a procedure that works, I am not suggesting that you rewrite it.