> 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>