the other day I ran a benchmark comparing perl hashes to apache tables. the basic methodology was to load both a perl hash and r->notes with the same data (in this case, linux.words on my system) then see how long it took to iterate over the entries and manipulate a few (all the entries starting with 'pr').
here are the results, all of which were generated in mod_perl handlers using Apache-Test:
iteration of perl hash in perl-space:
90 wallclock secs (89.61 usr + 0.01 sys = 89.62 CPU) @ 11.16/s (n=1000)
287 wallclock secs (287.20 usr + 0.02 sys = 287.22 CPU) @ 6.96/s (n=2000)
429 wallclock secs (428.09 usr + 0.02 sys = 428.11 CPU) @ 7.01/s (n=3000)
iteration of perl hash in XS:
20 wallclock secs (20.15 usr + 0.00 sys = 20.15 CPU) @ 49.63/s (n=1000)
38 wallclock secs (37.59 usr + 0.00 sys = 37.59 CPU) @ 53.21/s (n=2000)
61 wallclock secs (60.41 usr + 0.00 sys = 60.41 CPU) @ 49.66/s (n=3000)
iteration of r->notes using APR::Table::do() in perl-space:
239 wallclock secs (239.33 usr + 0.03 sys = 239.36 CPU) @ 4.18/s (n=1000)
last one times out, despite a high
476 wallclock secs (474.95 usr + 0.03 sys = 474.98 CPU) @ 4.21/s (n=2000)
Timeout value
iteration of r->notes using apr_table_do in XS:
10 wallclock secs ( 9.75 usr + 0.00 sys = 9.75 CPU) @ 102.56/s (n=1000)
19 wallclock secs (19.28 usr + 0.00 sys = 19.28 CPU) @ 103.73/s (n=2000)
29 wallclock secs (29.15 usr + 0.00 sys = 29.15 CPU) @ 102.92/s (n=3000)
one of the things that struck me as interesting was that the apache table algorithm is surprisingly fast when accessed through XS (and not so surprisingly slow when using APR::Table).
the other is that each of the approaches seems to have a one-to-one relationship between the number of iterations and the time required - 2000 iterations takes about twice as long as 1000. that is, except for perl hashes in perl-space, where the jump was significant. anybody have any ideas on that one? the code was pretty simple
sub fetch {
my $href = shift;
foreach my $key (keys %$href) {
$href->{$key}++ if $key =~ m/^pr/;
}
}
