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>
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
In reply to Re^7: Reusing a complex regexp in multiple spots, escaping the regexp
by LanX
in thread Reusing a complex regexp in multiple spots, escaping the regexp
by ecm
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |