Easier to do it yourself, or to fork () or not to fork ()

Solving the problem of calculating volume data in cycles often pulls the parallelization task.
Of course, in perl, there are just a couple of models: fork or thread, which allow the use of "multithreading". The implementation of each method and religious preferences to the material of this note do not apply.
We will talk about the reinforcement of the choice of "divide / not divide" numbers.

In short, the allocation of combing into a “separate stream”, besides the advantages, also carries a fat minus associated with the overhead of creating a descendant, communicating with it and maintaining it.
It is logical to assume that knowing the cost of overhead "multithreading" we can reasonably choose one or another architecture of your application. So you need to take and count, for example like this:

use Benchmark qw( timethese cmpthese ) ;

sub forked {
my $pid = fork;
$pid ? waitpid($pid, 0) : exit 0;
}

sub empty {
1;
}

my $r = timethese( -1, {
a => sub {forked(2)},
b => sub{empty(2)},
} );
cmpthese $r;

* This source code was highlighted with Source Code Highlighter .

As a result of a simple action we get something like:
')

Benchmark: running a, b for at least 1 CPU seconds...
a: 7 wallclock secs ( 0.09 usr 0.96 sys + 1.93 cusr 3.45 csys = 6.43 CPU) @ 278.69/s (n=1792)
b: 2 wallclock secs ( 1.11 usr + 0.01 sys = 1.12 CPU) @ 2730666.07/s (n=3058346)
Rate a b
a 279/s -- -100%
b 2730666/s 979709% --

* This source code was highlighted with Source Code Highlighter .

Ok, so the stream creation cycle and its maintenance gives us a maximum performance of 278.69 / s . This means that any calculation performed faster we consider ourselves, and we give children more and more cumbersome!
It is often to use the benchmark where the numbers allow to draw conclusions and make the right decision.