in reply to Can we make $& better?

In perl 5.10, $^MATCH will be equivalent to $& but at the same time the global speed penalties will not come into play. This means $& can be left alone.

The price to pay is that you will need to add the /p modifier flag to the pattern in order to tell perl that you want them. A reasonable trade-off.

• another intruder with the mooring in the heart of the Perl

  • Comment on Re: Can we make $& better? (no need with $^MATCH)

Replies are listed 'Best First'.
Re^2: Can we make $& better? (need)
by tye (Sage) on Sep 06, 2007 at 21:22 UTC

    Um, that gets rid of the global performance penalty but (as near as I can tell) keeps the local performance penalty, so I don't agree with "no need".

    If you are writing a parser that is spending most of its time applying regexes against potentially large strings, then the local penalty is plenty big of a penalty. It would be very nice to be able to use $& and $1 etc. w/o the local penalty with the caveat that those variables no longer work correctly if you modify the string most recently matched against (no, I'm not talking about being able to use $1 in s/// w/o the local 'copy' penalty).

    I vaguely proposed a /k option to prevent copying (and an option to prevent capturing, a somewhat related problem). I don't recall seeing such in the announcement and didn't find the announcement to check again.

    I don't even mind if $1 etc. can't be used directly. I'd just like to be able to disable the copying of the entire string while still being able to pull out the parts based on @- and @+ (a simple module could make these nearly as easy to use as $1 etc.).

    - tye        

      You still could allow changing the string to match against, and be able to read the contents of $1 and friends later, if a copy-on-write system was implemented. That way these match strings would only get copied in case your original string changes underneath.

      I'd prefer it if Perl was smart enough to skip the copy in case you don't need it, but I doubt it could be made so smart without a little manual help from a flag.

      The solution to the copy problem is to use m//g in scalar context which will NOT copy the string, and WILL result in the special match vars returning incorrect results if the string is changed after the fact.

      And yes, we did discuss some other options to control this behaviour, its just i never got around to dealing with them and now its too late for 5.10. Sorry about that.

      BTW, due to a misconception on my part I was extremely reluctant to add new modifiers. Im now much less reluctant as I resolved the misconception. The misconception was that adding new modifiers would break loads and loads of stuff, but further analysis proved that this was an unfounded concern.


        Wow. There needs to be a cheat sheet for this because every time it comes up I find mistakes, in this case my own. So my previous discovery that capturing parens cause the entire string to be copied is mostly not true. I assume the copy is required for s/// and s///g. Testing shows that otherwise the copy only happens for m// on modern perls (the 'scalar context' part doesn't appear to matter in my current testing) and doesn't even happen then with 5.6.

        It is nice that I can stop fearing the performance impact of capturing parens when doing the usual scalar-context m/.../gc of a parser. Thanks!

        - tye