Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: /o is dead, long live qr//!

by japhy (Canon)
on Jun 25, 2003 at 23:43 UTC ( #269055=note: print w/ replies, xml ) Need Help??


in reply to /o is dead, long live qr//!

There is not a noticeable increase in speed in using $x = qr/.../; /$x/ instead of $x = '...'; /$x/o; in the testing I have done. And the /o modifier is ONLY useful if the regex has any variables in it.

The place where qr// is important is when looping over strings and patterns. If you do a benchmark of code like this:

while (<>) { for my $p (qr/a+b/, qr/c+d/, qr/e+f/) { foo() if /$p/ } } # vs. while (<>) { for my $s ('a+b', 'c+d', 'e+f') { foo() if /$s/ } }
The qr// version will be considerably faster because Perl knows the regexes are already compiled, whereas in the string version, we need to compile three regexes for every line of input.

_____________________________________________________
Jeff[japhy]Pinyan: Perl, regex, and perl hacker, who'd like a job (NYC-area)
s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;


Comment on Re: /o is dead, long live qr//!
Select or Download Code
Re: Re: /o is dead, long live qr//!
by diotalevi (Canon) on Jun 25, 2003 at 23:46 UTC

    That's exactly what I said. The difference between $x as an object and $x as a string is a quick shortcut and an eq test.

Re: /o is dead, long live qr//!
by Abigail-II (Bishop) on Jun 26, 2003 at 00:32 UTC
    Actually, I tend to shy away from using qr, because they are dead slow when interpolating into larger constructs. Building large regexes from smaller parts is something I do often. Here's a benchmark showing a dramatic difference:
    #!/usr/bin/perl use strict; use warnings; use Benchmark qw /cmpthese/; cmpthese -2 => { qq => 'my $x = qq "[a]"; $x = qq "[a]$x" for 1 .. 100; "" =~ /$x +/', qr => 'my $x = qr "[a]"; $x = qr "[a]$x" for 1 .. 100; "" =~ /$x +/', } __END__ Benchmark: running qq, qr for at least 2 CPU seconds... qq: 6 wallclock secs ( 2.11 usr + 0.03 sys = 2.14 CPU) @ 5902.80/ +s (n=12632) qr: 4 wallclock secs ( 2.03 usr + 0.00 sys = 2.03 CPU) @ 39.90/s +(n=81) Rate qr qq qr 39.9/s -- -99% qq 5903/s 14693% --

    Abigail

      Too be fair, this is a problem with the *current* implementation of qr, and not the concept. Your two regexps are actually:
      #UPDATE: While the previous verbose format was more # impressive, it was hideously long. See the # readmore for the literal strings. $qq = "[a]"x100; $qr = "(?-xism:[a]"x100 . ")"x100;
      I think even a newbie could see that the latter is outrageously complicated...
        I know how the qr stringifies, and that's exactly the problem. However, when qr was introduced (which was long after perl5 as suggested elsewhere in this thread, I think it was 5.005) it was suggested that qr would be faster when interpolating. Even if you change the middle part of the benchmark to $x = qq "$x" and $x = qr "$x", the qq is three times as fast as the qr.

        I've had programs come to a grinding halt after using qr too liberaly.

        Abigail

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (9)
As of 2015-07-07 05:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (87 votes), past polls