in reply to Benchmarking regex alternation

Looks to me like the result is real. Adding a few more test cases is interesting:

use strict; use warnings; use Benchmark qw(cmpthese); my $pre = 250; my $post = 250; my $baz_match = ('b' x $pre) . 'baz' . ('b' x $post); my $bar_match = ('b' x $pre) . 'bar' . ('b' x $post); my $no_match = ('b' x $pre) . 'bza' . ('b' x $post); print "using_or_index ", using_or_index (), "\n"; print "using_or_noindex ", using_or_noindex (), "\n"; print "using_or_match ", using_or_match (), "\n"; print "using_or_nomatch ", using_or_nomatch (), "\n"; print "using_alt_match ", using_alt_match (), "\n"; print "using_alt_nomatch ", using_alt_nomatch (), "\n"; print "using_set_match ", using_set_match (), "\n"; print "using_set_nomatch ", using_set_nomatch (), "\n"; cmpthese( -1, { using_or_index => \&using_or_index, using_or_noindex => \&using_or_noindex, using_or_match => \&using_or_match, using_or_nomatch => \&using_or_nomatch, using_alt_match => \&using_alt_match, using_alt_nomatch => \&using_alt_nomatch, using_set_match => \&using_set_match, using_set_nomatch => \&using_set_nomatch, }); sub using_or_index { (-1 != index $baz_match, 'bar') or (-1 != index $baz_match, 'baz') + ? 1 : 0 } sub using_or_noindex { (-1 != index $no_match, 'bar') or (-1 != index $no_match, 'baz') ? + 1 : 0 } sub using_or_match { ($baz_match =~ /bar/ or $baz_match =~ /baz/) ? 1 : 0 } sub using_or_nomatch { ($no_match =~ /bar/ or $no_match =~ /baz/) ? 1 : 0 } sub using_alt_match { ($baz_match =~ /bar|baz/) ? 1 : 0 } sub using_alt_nomatch { ($no_match =~ /bar|baz/) ? 1 : 0 } sub using_set_match { ($baz_match =~ /ba[rz]/) ? 1 : 0 } sub using_set_nomatch { ($no_match =~ /ba[rz]/) ? 1 : 0 }

Prints:

using_or_index 1 using_or_noindex 0 using_or_match 1 using_or_nomatch 0 using_alt_match 1 using_alt_nomatch 0 using_set_match 1 using_set_nomatch 0 Rate using_alt_nomatch using_alt_match using_or_ +nomatch using_or_noindex using_set_nomatch using_or_match using_or_in +dex using_set_match using_alt_nomatch 9692/s -- -22% + -99% -99% -99% -99% - +99% -99% using_alt_match 12385/s 28% -- + -98% -98% -98% -98% - +98% -99% using_or_nomatch 667281/s 6785% 5288% + -- -4% -5% -17% - +19% -26% using_or_noindex 696846/s 7090% 5527% + 4% -- -1% -13% - +16% -22% using_set_nomatch 701884/s 7142% 5567% + 5% 1% -- -13% - +15% -22% using_or_match 804828/s 8204% 6399% + 21% 15% 15% -- +-2% -10% using_or_index 825420/s 8417% 6565% + 24% 18% 18% 3% + -- -8% using_set_match 898573/s 9172% 7155% + 35% 29% 28% 12% + 9% --

My guess is that the regex $str =~ /foo/ devolves to something pretty much like Index $str, 'foo' which can be pretty quick!

The surprise is how fast using a character set with a common prefix match is. That result also goes a long way to validating the benchmark.


DWIM is Perl's answer to Gödel

Replies are listed 'Best First'.
Re^2: Benchmarking regex alternation
by demerphq (Chancellor) on Jan 30, 2007 at 14:37 UTC

    the regex $str =~ /foo/ devolves to something pretty much like Index $str, 'foo'

    Yes exactly. Itll be a little slower than a index but only becuase there is a longer codepath from the regex-opcode to the actual FBM search than from the index-opcode.

    The surprise is how fast using a character set with a common prefix match is. That result also goes a long way to validating the benchmark.

    And it illustrates a new optimisation in 5.10:

    Rate using_alt_match using_or_nomatch using_alt_ +nomatch using_or_match using_alt_match 412710/s -- -29% + -30% -36% using_or_nomatch 580306/s 41% -- + -1% -9% using_alt_nomatch 585631/s 42% 1% + -- -9% using_or_match 640118/s 55% 10% + 9% -- 1631660

    Basically 5.10 is smart enough to convert /baz|bar/ into something close to /ba[rz]/. Its not quite as fast when written as an alternation due to current implmentation details, but it is very close.

    ---
    $world=~s/war/peace/g

      I wonder about /others/bar|baz|others/ if there are a lot of alternations, the probability of common prefixes decreases with the number of alternations or does it try to find common prefixes for close neighbours ?

      In the last 2-3 months on p5p was mentioned a few times the non-linearity of the regexp engine. The problem wrt to the internal utf8 representation is that at a given byte position you cannot really say what is the closest "character" position without knowing a previous correct one (the start for example is assumed ok). Is that the only cause of non-linearity? could you use markers to always keep correct "last" char. positions (cases with lots of backtracking could benefit of this, no? or is all that taken care of already in some smart way)

      Actually the "keeping all markers" trick reminds me for some reason of packrat parsing. Have you looked at packrat parsing in the context of regex? (wikipedia has links on the subject, and to the original haskell implementation of the algorithm) the algorithm seems to limit worse time behaviour of pathological NFA (non-posix) regexes to something roughly linear in the regex size

      thanks --stephan

      update: corrected typo if to is