in reply to qr//i versus m//i

/$qr/i isn't doing what you think it is. It's not doing a case-insensitive match. The '/i' doesn't override how the pattern has already been compiled. This is why it appears about as fast as the qr//+m// variant.

Note also that case-insensitive matching is always going to be much slower than case-sensitive matching, especially when UNICODE is involved. And in particular, case-sensitive matching of fixed strings, such as in your benchmark, is specifically optimised (the main regex engine isn't actually called - instead a Boyer-Moore matcher is called instead). Which is why your benchmark makes the case-insensitive match look particularly bad.

Dave.

Replies are listed 'Best First'.
Re^2: qr//i versus m//i
by hazylife (Monk) on Feb 22, 2014 at 12:26 UTC

    > The '/i' doesn't override how the pattern has already been compiled.

    Oh, I see. You're right Dave, my bad.

    > Note also that case-insensitive matching is always going to be much slower than case-sensitive matching, especially when UNICODE is involved.

    It really is awfully slow:

    $ RE=... # an actual regex here
$ time fbgrep.pl "$RE" *fb2* >/dev/null
real    0m32.912s
user    0m32.374s
sys     0m0.483s

$ time fbgrep.pl -i "$RE" *fb2* >/dev/null
real    2m17.575s
user    2m16.359s
sys     0m0.421s

    [download]

    But I suppose there's not much to be done about it.

    Thanks for pointing me in the right direction!

[reply]
[d/l]

In Section Seekers of Perl Wisdom