Que?

So patterns compiled with qr// are 'dynamic' unless I use the /o modifier? Could you explain your definition of 'static' in this context? Can you give me a reference to this information?

2) & 3) - I think I would want considerably more factual information regarding what runtime steps are prevented from repetition by the use of qr// than I can derive from your breif quote, before I could draw any conclusions, never mind your definitive statement.

4) So, did I benefit, in terms of runtime performance from pre-compiling some parts of the final pattern? Or am I in effect forcing the pre-compiled parts of the regex to be re-inspected? Would it actually be better to simply put all the parts together in a single regex with the /o modifier so that the compiler only needs to process everything one time?

5) From what source do you derive that conclusion?

It would make sense to me that if I use qr// or possibly the /o (which I think amount to pretty much the same thing, but am open to correction), that if the regex contains one or more sets of capture brackets, grouping brackets, repetition modifiers etc. It could be possible to pre-build a parsing tree (or somesuch) so that (for example) the size of the @+ and @- arrays could be pre-allocated and pointed to rather than needing to do this at runtime. However, if this was done for 2 seperate patterns each containing a set of capture brackets, when they become combined together, that pre-allocation needs to change.

Whilst there may be some benefit in combining two pre-parsed regexes together by using whatever data-structures are built internally to represent them, when these are further combined with non-precompiled parts, it might simply be quicker to have the regex engine build the internal data-structure to represent the entire pattern in a single pass rather than parsing the non-compiled parts, having to take into account the effects that the embedded pre-compiled parts have on (for example) capture bracket numbering.

I would like to know, without needing to resort to source-diving, which of the two approaches is used, and which has the least impact at runtime?