in reply to Re^5: Surprisingly poor regex performance
in thread Surprisingly poor regex performance

How does it compare to (?:\A|(?<=\n)) ? Isn't that the accurate representation of /^.../m ? You could also try (?<![^\n]) which seems somehow even simpler.

- tye        

Replies are listed 'Best First'.
Re^7: Surprisingly poor regex performance (apples)
by dragonchild (Archbishop) on Dec 14, 2004 at 17:32 UTC
    Using the benchmarking code above ... 
    timethese( 100, {
 'better' => sub {
     while ($mmap =~ m/(?:\A|\n)(.*$pat.*\n)/omg) {
     }
 },
 'tye1' => sub {
     while ($mmap =~ m/(?:\A|(?<=\n))(.*$pat.*\n)/omg) {
     }
 },
 'tye2' => sub {
     while ($mmap =~ m/(?:\A|(?<![^\n]))(.*$pat.*\n)/omg) {
     }
 },
})
__END__
Benchmark: timing 100 iterations of better, tye1, tye2...
    better: 11 wallclock secs (10.61 usr +  0.00 sys = 10.61 CPU) @  9
+.43/s (n=100)
      tye1: 13 wallclock secs (12.37 usr +  0.00 sys = 12.37 CPU) @  8
+.08/s (n=100)
      tye2: 14 wallclock secs (14.16 usr +  0.00 sys = 14.16 CPU) @  7
+.06/s (n=100)

    [download]

    I have no idea how to figure out why these numbers are the way they are. The only thing I can think of is that the lookaround assertion takes more time than the actual character check. *shrugs*

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
[d/l]

      I'm not surprised that a look-behing assertion takes longer than something like (?:\A|\n), especially by this small of a margin. What wouldn't make sense to me would be that /^.../m would be 15x slower than either of the regexes I proposed unless I was missing some feature of ^ that isn't captured by my proposals.

      Perhaps ^ needs to be re-implemented as using the regex operations used to implement either of my proposals (since look-behind assertions weren't available when the ^ code was written and so it might use something much worse and your testing seems to show that it does).

      - tye        

[reply]
[d/l]

In Section Seekers of Perl Wisdom