Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: An optimization of last resort: eliminate capturing from your regexps

by graff (Chancellor)
on Jul 11, 2006 at 05:26 UTC ( #560315=note: print w/ replies, xml ) Need Help??


in reply to An optimization of last resort: eliminate capturing from your regexps

So, is it really the case that using @- and @+ like you do here does not cause the runtime penalty that is imposed by using the "match" variables ( $`, $&, $' ) ? If so, that's good to know...

perlvar (in my current 5.8.6) still has the warning about the impact of using any of those three match variables in a script, but that impact is not mentioned at all in the sections about @+ and @- (however the latter does indicate how to use these arrays to get the same values as what the match variables would give you).


Comment on Re: An optimization of last resort: eliminate capturing from your regexps
Download Code
Re^2: An optimization of last resort: eliminate capturing from your regexps
by davido (Archbishop) on Jul 11, 2006 at 07:02 UTC

    Correct, really, @- and @+ do not impose the performance penalties incurred with $', $&, and $`. Think of the @- and @+ variables as simply keeping track of where something was seen, whereas the 'match' variables keep copies of what was seen. It's quicker to bookmark page nine than it is to memorize it. ;) (ok, that's a bit of a simplistic exaggeration, but it should get the idea across)


    Dave

Re^2: An optimization of last resort: eliminate capturing from your regexps
by demerphq (Chancellor) on Jul 11, 2006 at 08:56 UTC

    Just so you know... $1 et all are basically ties that do something like

    substr($something, $-[$digit], $+[$digit] - $-[$digit]);

    Part of the reason for this is that internally perl doesnt populate $1 et all with copies when it runs the regex as when backtracking it could have to recopy the contents of these vars many many times. Wheras updating the appropriate offsets is cheap and constant time.

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

      They're not actually ties though. Ties are slow, these aren't.

      ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Re^2: An optimization of last resort: eliminate capturing from your regexps
by diotalevi (Canon) on Jul 11, 2006 at 13:51 UTC

    True. Using @- and @+ does not invoke the $`, $&, $' penalty. The $@ penalty is just the memcpy penaly I mentioned except it is enabled for all regexps, even the non-capturing ones. Any regexps that already use capturing can't be penalized anymore and aren't any slower because of it.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Re^2: An optimization of last resort: eliminate capturing from your regexps (hit)
by tye (Cardinal) on Jul 11, 2006 at 14:28 UTC

    Hopefully to be somewhat clearer, $`, $&, and $' are especially bad because once they've been seen by Perl, all regexes will do extra work.

    Capturing in a regex imparts a performance hit because it means that a copy will be made of the string that the regex is being applied to (which makes it a worse performance hit when matching against really large strings -- one of the worst cases being running a lot of little regexes with capturing against the same huge string, something a parser is likely to do). The performance hit of capturing only applies to the regex that does capturing and most of the time it isn't enough that you'd notice.

    @- and @+ are always set by regexes and whether you use them or not doesn't have any performance impact at all.

    I'm curious why the regex engine doesn't just copy out the parts that were captured and only copy them after the regex has finished. That seems like a "best of both worlds" solution. Though, I think /k would be really cool, especially if you could use it with:

    @matches= $string =~ /$regex/gk;

    to make it so it doesn't matter whether $regex contained capturing parens or not. (:

    Finally, this benchmark shows that the per-regex performance hit from $`, $&, and $' is the same hit from capturing parens:

    #!/usr/bin/perl -w use strict; use Benchmark qw( timethis cmpthese ); my %t; my $pref= "no&"; my $str= "match" . ( "garbage" x 500 ); for( 0, 1 ) { $t{$pref."?:"}= timethis( -3, sub { $str =~ /(?:match)+/; } ); $t{$pref."()"}= timethis( -3, sub { $str =~ /(match)+/; } ); eval '$&'; $pref= "amp"; } cmpthese( \%t ); __END__ Rate amp() no&() amp?: no&?: amp() 439813/s -- -0% -1% -81% no&() 441612/s 0% -- -0% -81% amp?: 443563/s 1% 0% -- -81% no&?: 2354611/s 435% 433% 431% --

    But, remember: $`, $&, and $' are evil while capturing parens are usually the best solution when you need them and usually don't cause a noticeable performance penalty.

    - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://560315]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2014-11-27 19:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (187 votes), past polls