• Dave_the_m says the qr object is always duplicated because matches depend on scope.
• Aristotle says, using an additional /o modifier closes the performance gap ... but will alter the semantics
• Demerphq says he doesn't know what's going on.

Anyway I'm confused, there may be a difference if a $var= qr/.../ is used directly as a RHS of a match or is interpolated inside a bigger regex.

And since it's possible to stringify a qr-object and use the string instead, this adds another layer of confusion.

I have to think hard about a concise way to test all of this which wouldn't result in a tl;dr monstrum.

Note the (?(DEFINE)...) construct has it's own performance issue. From (DEFINE):

patterns defined this way probably will not be as efficient, as the optimizer is not very clever about handling them.

Also, all DEFINE'd patterns are capturing, even if you don't need it, so that is another minor hit against performance. This can also be confusing if you are trying to refer to capture groups by absolute number instead of by name.

I'm still not convinced that nesting qr// snippets into larger qr// parts is such a show stopper.

Are they stored as nested objects causing overhead? (Hmm probably... I read something in the docs about them acting like closures.)

But what if I stringify/flatten the outcome and recompile it, even with a /o once modifier? This should reset most effects.

Unless context switches like different nested modifiers like /i cause new overhead...(?)

  DB<1> p qr/[0-9a-f]/i
(?^ui:[0-9a-f])
  DB<2> $x=qr/[0-9a-f]/i

  DB<3> $hex_range= qr/$x+ - $x+/x

  DB<4> say $hex_range
(?^ux:(?^ui:[0-9a-f])+ - (?^ui:[0-9a-f])+)

  DB<5>
[download]

I'll put this on my to-do list, and will try to dive deeper next weekend.

Like running benchmarks and looking into the op-tree.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}