Thank you for the link! Having now read that, I've learned a few things.
- An expression without /o does indeed not recompile if it hasn't changed, but there's still an overhead of comparing the "new" string to the old string to decide whether to recompile. In my tests, my strings are kind of long (1_000 characters), so this overhead is more apparent.
- The /o on a qr actually does do something—something just like it does on any other match.
- A literal qr actually gets compiled at compile time. That shouldn't be a surprise, but I didn't know it.
Looking at my test results some more, I guess my anomalous case was one where matching took an extra long time, and the overheads got washed out of the results. Since I told Benchmark to run a fixed number of seconds rather than a fixed number of iterations, there were fewer iterations and less overhead resulted. That makes the "compiled once" qr constructs look about the same as the "compiled once" m//o.
| [reply]
[d/l]
[select] |
While I admit it's possible to construct a regexp that is executed more than once that is somewhat faster with /o than without, I strongly urge people not to use /o.
Basically, there are two cases where you may want to use /o:
- /...${var}.../o, where you think ${var} doesn't change.
- /...${var}.../o, where you think ${var} changes.
Note that in case 1), leaving off /o is never wrong. However, if you keep /o, and it turns out that $var does actually change between executions (either because you were mistaken about $var changing, or the code was changed and $var now changes), the code is wrong, as it be as if $var retained its old value.
In case 2), were you want the regexp to act as if $var hasn't change, I'd pity the programmer (even if it's you) who has to maintain that code. It's quite obfuscated.
So in short, IMO, the performance gain doesn't overcome the drawback of (possible) "action over time" (akin "action at a distance").
I never use /o, and /o is a red flag in my book.
| [reply]
[d/l]
[select] |
| [reply] |