Can you provide a link? To compare a scalar numerically, Perl needs to check the flag that says it's okay to use as a number, convert it to a number, stow the number in the SV, set the okay to use as a number flag, and perform the comparison.

Of course, to compare it as a string, it has to do the same sort of thing with the okay to use as a string flag.

Besides all that, if mangling your program to use numeric equals really speeds it up, you're either a better programmer than anybody I've known or you should probably consider dropping to C. Please program for accuracy, not speed.

Actually i think i read it in Mastering Algorithms with Perl even though i cannot find it right now.

Anyway to wipe out your doubts you can try a benchmark:


#!/usr/bin/perl

use strict;
use Benchmark qw(:all);

cmpthese(10, {
    'eq'    =>  sub {
        for (my ($i, $j) = (0, 0); $i < 1_000_000; $i++) {
            $j++ if ($i % 3) eq 2;
        }
    },
    '=='    =>  sub {
        for (my ($i, $j) = (0, 0); $i < 1_000_000; $i++) {
            $j++ if ($i % 3) == 2;
        }
    },
});

__END__
Benchmark: timing 10 iterations of ==, eq...
        ==: 28 wallclock secs (27.91 usr +  0.00 sys = 27.91 CPU) @  0
+.36/s (n=10)
        eq: 36 wallclock secs (36.16 usr +  0.01 sys = 36.17 CPU) @  0
+.28/s (n=10)
   s/iter   eq   ==
eq   3.62   -- -23%
==   2.79  30%   --
[download]

The test was run on my Powerbook G3 with Perl v5.8.0 built for powerpc-linux-thread-multi.

I agree we shouldn't program for speed only, but here speed and good form comes from the same expression. Also you may note how my first post in this thread started out with "Also": it wasn't meant to be a comprehensive response to c's problem, but instead my 2 cents to what already said.


$|=$_="1g2i1u1l2i4e2n0k",map{print"\7",chop;select$,,$,,$,,$_/7}m{..}g

Was your point trying to prove chromatics point? Because IMO, all your benchmark shows is that having to do an atoi takes time. Because in both tests, the left hand side of the operator is the outcome of a module operation, the %. And that's numeric.

Here's a different benchmark. One that used both numbers and string, and both == and eq. You will see that the fastest cases are when no conversions needs to take place. Conclusion: use eq when comparing strings, and == when comparing numbers if speed is your main motivation.

#!/usr/bin/perl

use strict;
use warnings;
use Benchmark qw /cmpthese/;

our ($a, $b, $c, $d);

cmpthese -10 => {
    '==-num' => '$::a = 0;
                 for my $i (0 .. 1000000) {
                     $::a ++ if $i == 100;
                 }',
    'eq-num' => '$::b = 0;
                 for my $i (0 .. 1000000) {
                     $::b ++ if $i eq "100";
                 }',
    '==-str' => '$::c = 0;
                 for my $i ("0" .. "1000000") {
                     $::c ++ if $i == 100;
                 }',
    'eq-str' => '$::d = 0;
                 for my $i (0 .. "1000000") {
                     $::d ++ if $i eq "100";
                 }',
};

print "[$a] [$b] [$c] [$d]\n";

__END__
Benchmark: running ==-num, ==-str, eq-num, eq-str, each for at least 1
+0 CPU seconds...
    ==-num: 10 wallclock secs (10.02 usr +  0.00 sys = 10.02 CPU) @  4
+.19/s (n=42)
    ==-str: 10 wallclock secs (10.25 usr +  0.01 sys = 10.26 CPU) @  1
+.75/s (n=18)
    eq-num: 10 wallclock secs (10.06 usr +  0.01 sys = 10.07 CPU) @  2
+.38/s (n=24)
    eq-str: 10 wallclock secs (10.28 usr +  0.00 sys = 10.28 CPU) @  2
+.43/s (n=25)
         Rate ==-str eq-num eq-str ==-num
==-str 1.75/s     --   -26%   -28%   -58%
eq-num 2.38/s    36%     --    -2%   -43%
eq-str 2.43/s    39%     2%     --   -42%
==-num 4.19/s   139%    76%    72%     --
[1] [1] [1] [1]
[download]

Abigail