Re: Performance of possessive quantifiers

[tsee]

in reply to Performance of possessive quantifiers

Seemed odd to me, so I ran it on 5.8.8 and the current bleadperl 5.11. The absolute numbers for my computer are, of course, different, but the general observation holds for 5.11. The really disturbing part is that 5.8.8 executes the atomic1/2 cases at about the same speed as "normal". Oh, and on a side note: The difference in execution speed of 5.11's "normal" and 5.8.8's "normal" may be due to 5.11 being a debugging build and all, so it's not necessarily significant.

#!/usr/bin/perl
use strict;
use warnings;
use version;
use Benchmark qw(cmpthese);

my $str = "bea" x 100;
my $re = qr/(?:be|ea|a)/;
cmpthese(-2, {
    atomic1   => sub { die if $str =~ m/(?>$re+)\d/ },
    atomic2   => sub { die if $str =~ m/(?>$re)+\d/ },
    normal    => sub { die if $str =~ m/$re+\d/ },
    ( version->new($]) >= version->new("5.10.0")
      ? (posessive => sub { die if $str =~ m/$re++\d/ })
      : ()
    ),
});
__END__
5.8.8:

          Rate  normal atomic2 atomic1
normal  5000/s      --     -4%    -18%
atomic2 5208/s      4%      --    -15%
atomic1 6132/s     23%     18%      --

5.11:
            Rate posessive   atomic1   atomic2    normal
posessive 59.9/s        --       -1%      -97%      -97%
atomic1   60.4/s        1%        --      -97%      -97%
atomic2   1953/s     3159%     3134%        --       -9%
normal    2156/s     3500%     3472%       10%        --

I'm hoping for demerphq to chime in with an explanation. :)

Cheers,
Steffen

[demerphq]

try

m/(?>$re)+(*SKIP)\d/

on 5.11

And it looks like something broke the superlinear cache. Even with atomic matching this pattern/string combination goes quadratic, as nothing anchors the start of the pattern. Without the atomic matching its worse. Im not sure what the deal is with $re++ either. I would have expected that to have similar performance to (?>$re)+, its possible thats actually a bug. Ill have to think about it.

Oh, and dont use benchmarks from a debugging perl. Depending on the code path you go through variable amounts of debugging goo, so using a debugging perl, especially a 5.9.x or later version will not give useful results even comparing features.

[tsee]

Ah, thanks for that last remark, I'll keep it in mind for future testing.

However, I double-checked and while I thought I remembered that -Dusedevel implied -DDEBUGGING, it doesn't seem so*. Hence, the 5.11 I used for the above results was no debugging build. Sorry for the confusion!

Cheers,
Steffen

* I did "./Configure -Dusedevel -de 2>&1 | grep -i debug" and "make -j3 | grep -i debug" without any mention of DEBUGGING.

[moritz]

The -Dusedevel option to Configure just quiets the "WHOA THERE, is this a development version of perl" message that otherwise quits Configure.

I verified my original benchmarks with non-debugging perls (I wasn't sure if my 5.10 had been debugging, and I missed to look at perl5.10.0 -V ;), it didn't change anything.