I was trying to decide what's the best storage to use in the
Apache-Registry modules, and whether to store frequently used $r info or
request for them every time I need them. So I've decided to benchmark
(See my other post about Apache::Benchmark :).
This is the relevant snippet from the Benchmark.
use constant URI => 4; # there are other elements inside
sub uri{ shift->[URI]; }
sub handler {
my $r = shift;
my $a = [];
$a->[URI] = $r->uri;
my $uri = $r->uri;
my $ba = bless [], __PACKAGE__;
$ba->[URI] = $r->uri;
my %code =
(
scalar => sub {my $x = $uri },
array_bless => sub {my $x = $ba->[URI]},
array_method => sub {my $x = $ba->uri },
array => sub {my $x = $a->[URI] },
native_method => sub {my $x = $r->uri },
);
then I feed %code into Benchmark.pm, so I get this (count = 1M):
scalar 1 wallclock secs ( 0.54 usr + -0.01 sys = 0.53 CPU)
array 0 wallclock secs ( 0.99 usr + -0.01 sys = 0.98 CPU)
array_bless 1 wallclock secs ( 0.97 usr + 0.01 sys = 0.98 CPU)
native_method 1 wallclock secs ( 2.47 usr + 0.01 sys = 2.48 CPU)
array_method 6 wallclock secs ( 5.56 usr + 0.00 sys = 5.56 CPU)
So it seems that my choice of using a blessed array was almost the
optimum one, since I didn't want to pass variable number of arguments
around. The scallar is still about twice faster.
I didn't even test a hash, since scalar is always at least as fast as a
hash of the same size. And I use constants to access fields, so the code
is easy to read, which also add compile time error-checking.
As you can see using nice methods for accessing stored data is a way
slower than direct access. Hope that's OK for the sake of extra saved
millisecond :)
Sometimes the difference in two methods is negligible, but if you adher
your coding style to use the fastest, without making the code less
maintainable and extensible, I think it's a good thing to do. I don't
call this kind of benchmarking a premature optimization. Usually you
don't get time allotted for optimizations when the code is completed, so
it's a win-win to know how to code for performance in first place.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
