I admit that I thought the enormous sz from ps in each child processes I forked came from its own instance of the Perl intrepreter, but I never claimed that HPUX didn't use copy-on-write.

My problem is I have no way of profiling it - how can I tell how much memory is really being used and how much is shared.

I have thought of a few more ways to optimize speed and memory allocation of the original code, but that won't get rid of the overhead I mentioned by my example of just a simple script.

#!/usr/bin/perl -w
use strict;
while (1) {
  print "I am only printing and sleeping\n";
  sleep 1;
}
[download]

That tiny program shows up in ps with a sz comparable to my full blown script.

If I can't tell how much of that is shared by fork'ing another process - I have no idea if the project is viable or if it should be scrapped.

Now your proposal is a tad bit different from the others as your forked children die returning all memory to the system, they are just spawned each iteration, which means the memory is MORE available (during sleep) to the system and since all the variables will be pretty stagnant once the child is forked - it won't start getting dirty before its dead. This is food for thought.

Thanks and cheers - L~R

Not exactly, my solution (although badly worded that late at night) was to (in psudo code):

while (1) {
$totallistoffiles = glob all_dir_list/*;
fork
if child { 
proccess file list
exit
}
else #parrent {
sleep 2
}
}
[download]

The parrents task is to grab the list of files (read all 20 directories) every x seconds fork and create a child that proccesses such list -- only to loop sleep and do it all over in x seconds. your only downside here is that the child has to (on average) execute faster than the sleep time of the parent otherwise you will slowly gain procs. I hope this clears it up.

-Waswas