http://qs321.pair.com?node_id=276045


in reply to eq vs. ==

Also somewhere in the documentation is noted that == is much cheaper than eq, so you may wanna use == whenever it makes sense.

UPDATE: i guess there is some misunderstanding here. My line above saying "so you may wanna use == whenever it makes sense" must be read as "please use == when comparing something that should be a number, because using eq to compare two numbers is much less efficient". On the other side using == to compare two strings is less likely to give the result you want, so i didn't consider that case. Hope now it's clear.


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

Replies are listed 'Best First'.
Re: Re: eq vs. ==
by chromatic (Archbishop) on Jul 20, 2003 at 17:09 UTC

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

        Abigail