> In benchmarking some code I've come across something I did not expect:
>
You have to stop spending so much time playing with all this bogus
benchmarking :)
> slice:
> use strict;
> use warnings;
> my @k=qw(1 2 3 4 5 6);
> my %n;@[EMAIL PROTECTED] = @k;
> print "hi" if exists $n{1};
> print "hi" if exists $n{3};
> print "hi" if exists $n{5};
> print "hi" if exists $n{7};
> print "hi" if exists $n{9};
> print "hi" if exists $n{11};
>
> grep:
> use strict;
> use warnings;
> my @k=qw(1 2 3 4 5 6);
> print "hi" if grep /^1$/, @k;
> print "hi" if grep /^3$/, @k;
> print "hi" if grep /^5$/, @k;
> print "hi" if grep /^7$/, @k;
> print "hi" if grep /^9$/, @k;
> print "hi" if grep /^11$/, @k;
>
>
>
> Benchmark: timing 5000000 iterations of grep, slice...
> grep: 3.65945 wallclock secs ( 2.33 usr + 0.04 sys = 2.37 CPU)
> @ 2109704.64/s (n=5000000)
> slice: 2.37966 wallclock secs ( 2.52 usr + -0.01 sys = 2.51 CPU)
> @ 1992031.87/s (n=5000000)
> Rate slice grep
> slice 1992032/s -- -6%
> grep 2109705/s 6% --
>
> I would've thought the "slice and then use exists" would have been
> faster then "greping the entire array each time and using regexes" when
> you check it. but its consistently faster by an average 6-10%
>
> Any ideas why that might be?
Well, first -- you're creating the hash inside the benchmark loop,
which is not particularly light-weight.
Second: You're using pathologically small lists. Try running it with
10,000 elements instead of ten.
Third: Premature optimization is a terrible thing.
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
