This section is from the "Practical mod_perl" book, by Stas Bekman and Eric Cholet. Also available from Amazon: Practical mod_perl
The above results don't mean that you shouldn't use methods. Generally your functions do something, and the more they do the less significant the overhead of the call itself becomes. This is because the calling time is effectively fixed and usually creates a very small overhead in comparison to the execution time of the method or function itself. This is demonstrated by the next benchmark (see Example 13-16).
package Book::HeavySub; use strict; use Benchmark; sub bar { my $class = shift; my ($x, $y) = (100, 100); $y = log ($x ** 10) for (0..20); }; timethese(100_000, { method => sub { Book::HeavySub->bar( ) }, function => sub { Book::HeavySub::bar('Book::HeavySub');}, });
We get a very close benchmark!
panic% ./bench_call2.pl function: 5 wallclock secs ( 4.42 usr + 0.02 sys = 4.44 CPU) method: 5 wallclock secs ( 4.66 usr + 0.00 sys = 4.66 CPU)
Let's make the subroutine bar even heavier, by making the for( ) loop five times longer:
sub bar { my $class = shift; my ($x, $y) = (100, 100); $y = log ($x ** 10) for (0..100); };
The result is:
function: 18 wallclock secs (17.87 usr + 0.10 sys = 17.97 CPU) method: 19 wallclock secs (18.22 usr + 0.01 sys = 18.23 CPU)
You can see that in the first and second benchmarks the difference between the function and method calls is almost the same: 0.22 and 0.26 CPU clocks, respectively.
In cases where functions do very little work, the overhead might become significant. If your goal is speed you might consider using the function form, but if you write a large and complicated application, it's much better to use the method form, as it will make your code easier to develop, maintain, and debug. Saving programmer time over the life of a project may turn out to be the most significant cost factor.
 
Continue to: