Re: Re: meaning of /o in regexes

[slife]

1. Why does the qr// operator accept the /o midifier?

So that you can create a 'static' compiled regex object that can be interpolated in to more complex patterns subsquently in the program.

2. If you combine one or more parts defined with qr// in a regex with some non-precompiled stuff, do you still get the advantage of precompilation?

The discussion on p194 of Camel 3rd Ed. states that you can 'chain' qr// operaters into one pattern to prevent re-compilation, so the answer would appear to be 'no'.

3. If there was a non-compiled var reference in the above m//, do I still get any benefit from pre-compiling the other parts?

No; again, according to the reference above, the pattern would be re-compiled.

4. What happens if I add a /o modifier to the m// above?

You'd get a once-only compilation of the pattern.

5. If one or more of the per-compiled parts (and/or the non-precompiled parts) contains capture brackets, was there any benefit (in performance terms) from pre-compiling some parts?

I doubt that the presence or absence of capture brackets makes much difference to whether or not precompilation provides any benefit.

[BrowserUk]

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?

---

Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.