in reply to Re: Why does global match run faster than none global?
in thread Why does global match run faster than none global?

I can't replicate your results with the two versions I currently have installed on this machine:

$ /usr/local/bin/perl5.10.1 921987.pl Rate b a c d b 4497569/s -- -2% -21% -26% a 4591346/s 2% -- -19% -25% c 5681139/s 26% 24% -- -7% d 6116693/s 36% 33% 8% -- $ /usr/local/bin/perl5.10.1 -v This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi $ /usr/local/bin/perl5.12.2 921987.pl Rate a b c d a 4314282/s -- -8% -30% -36% b 4677165/s 8% -- -24% -31% c 6168093/s 43% 32% -- -9% d 6779346/s 57% 45% 10% -- $ /usr/local/bin/perl5.12.2 -v This is perl 5, version 12, subversion 2 (v5.12.2) built for x86_64-li +nux-thread-multi

If there is any significant difference at all, it tends to be the other way around, i.e. /g is slower.

Replies are listed 'Best First'.
Re^3: Why does global match run faster than none global?
by BrowserUk (Patriarch) on Aug 23, 2011 at 22:26 UTC

    No matter how long I run it for, it is remarkably consistent here with no more than 1 or 2% variation:

    C:\test\perl-5.14.0-RC1>perl use Benchmark qw[ cmpthese ];; print $];; $str = '123456789'; cmpthese -10, { a=>q[ my ($a,$b) = $str =~ m/(23)[^8]+(8)/g; ], b=>q[ my ($a,$b) = $str =~ m/(23)[^8]+(8)/; ], c=>q[ my ($a) = $str =~ m/(23)/g ], d=>q[ my ($a) = $str =~ m/(23)/; ], };; ^Z 5.014000 Rate b a d c b 357543/s -- -15% -33% -45% a 422192/s 18% -- -21% -35% d 535621/s 50% 27% -- -18% c 653518/s 83% 55% 22% --

    One difference of note is that I'm using Window rather than your Linux. Your results reflect ikegami's, who I believe was also using Linux. Perhaps the OP is on Windows?

    The 'usual suspect' for performance differences a between those two is memory allocation, but there is none worthy of note here. Indeed, there appear (as you would suspect), to be no calls at all into the OS during benchmark.

    Since were both on 64-bit intel hardware, that doesn't seem likely as a cause. Which pretty much leaves only compiler differences, with teh tentative conclusion that with the /g switch enabled, the Windows takes a code path that causes (or allows) the MSC compiler to generate a particularly efficient piece of code somewhere.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Which pretty much leaves only compiler differences...

      That was my conclusion, too.

      BTW, on second glance I noticed that your figures are about an order of magnitude slower in absolute terms, compared to what I and the others got — which made me wonder what hardware you were using.

      Don't get me wrong, I'm not into some childish "mine is bigger" kind of silly thing... Not at all, it's just that if we presume roughly comparable hardware, what might account for that order-of-magnitude difference?  Compiler differences, too?

      Just for comparison, the CPU I ran the test on is a 2.3 GHz AMD Phenom 9600 quad-core — which was already pretty "standard" at the time I bought the machine 3 years ago. (The quad-core should be irrelevant here, as the benchmark uses one core only anyway.)

        on second glance I noticed that your figures are about an order of magnitude slower in absolute terms, compared to what I and the others got

        Hm. I have an Intel Core2 Quad Q6600 @ 2.4 GHz. So now I'm really baffled!


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        I noticed that your figures are about an order of magnitude slower in absolute terms,

        There appears to be nothing wrong with my set-up, and nothing I tried has allowed me to start and stop the regex engine in less than 1 microsecond.

        I strongly suspect that all the timing showing millions/s are wrong. I think that the posters have tested code along the lines of:

        use Benchmark qw[ cmpthese ]; my $str = '123456789'; cmpthese -1, { a=>q[ my ($a,$b) = $str =~ m/(23)[^8]+(8)/g; ], b=>q[ my ($a,$b) = $str =~ m/(23)[^8]+(8)/; ], c=>q[ my ($a) = $str =~ m/(23)/g ], d=>q[ my ($a) = $str =~ m/(23)/; ], };;

        Note the my which means that when the tested are evaluated $str will be undefined.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re^3: Why does global match run faster than none global?
by Kc12349 (Monk) on Aug 23, 2011 at 21:41 UTC

    I think we (or at least I) may be chasing noise. I can't replicate the larger 20% number. Additionally I get noise in both directions on multiple runs. My guess would be over enough iterations we'd see a slightly slower /g.

    use Benchmark qw[ cmpthese ];; my $str = '123456789'; cmpthese -1, { a=>q[ my ($a,$b) = $str =~ m/(23)[^8]+(8)/g; ], b=>q[ my ($a,$b) = $str =~ m/(23)[^8]+(8)/; ], c=>q[ my ($a) = $str =~ m/(23)/g ], d=>q[ my ($a) = $str =~ m/(23)/; ], }; Rate a b c d a 7047422/s -- -2% -26% -29% b 7218432/s 2% -- -25% -28% c 9578119/s 36% 33% -- -4% d 9960542/s 41% 38% 4% -- Rate a b c d a 7143583/s -- 2% -24% -24% b 7005183/s -2% -- -25% -25% c 9378794/s 31% 34% -- -0% d 9387510/s 31% 34% 0% --
Re^3: Why does global match run faster than none global?
by BrowserUk (Patriarch) on Aug 25, 2011 at 04:13 UTC

    You did ensure that $str was defined as our not my didn't you?