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

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%     --

[download]

Abigail

Replies are listed 'Best First'.
Re: Re: /o is dead, long live qr//!
by belg4mit (Prior) on Jun 26, 2003 at 01:02 UTC
    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;

    [download]
    I think even a newbie could see that the latter is outrageously complicated...
    Read more... (5 kB)
[reply]
[d/l]
[select]
      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

[reply]
[d/l]
[select]
        Right. However, one might not unreasonably claim that the Right Thing for qr to do is clean its input if it is given the output from another qr to avoid such messes.

        UPDATE: Meanwhile, a possible solution is to uh, not nest qrs? ie; use the original strings to build up a single expression passed to qr. If anything, that ought to be simpler than using qr'd segments, and saves steps.

        --
        I'm not belgian but I play one on TV.

[reply]

        I don't recall ever suggesting that qr objects should actually be interpolated. The only reason I ever interpolate those is because I can write the original regex without having to go backwhack happy on \s and friends. There's also not much point in interpolating qr objects because you get bit for compiling that bit more than once anyway. But you knew all that anyway. *grin*

        But given the nature of qr, I don't see why you'd want to keep stables of them around just to interpolate them anyway. The whole point of a qr object is that it is a complete regex. Also, once that complex regex is parsed all the frippery is thrown away anyway so it doesn't really change runtime performance. So I don't think you've said anything about why not to use qr. You just stated that it isn't useful to keep qr objects around if they're just going to be interpolated back into other expressions.

[reply]

In Section Meditations