Re^2: Can we make $& better? (need)

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

Comment on Re^2: Can we make $& better? (need)

Replies are listed 'Best First'.
Re^3: Can we make $& better? (need) by bart (Canon) on Sep 07, 2007 at 20:28 UTC
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.	[reply]
Re^3: Can we make $& better? (need) by demerphq (Chancellor) on Sep 12, 2007 at 18:22 UTC
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. --- $world=~s/war/peace/g	[reply]
Re^4: Can we make $& better? (need) by tye (Sage) on Sep 12, 2007 at 19:12 UTC
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	[reply]
Re^5: Can we make $& better? (need) by demerphq (Chancellor) on Sep 12, 2007 at 19:24 UTC
Hrm, ill have to check the code in more detail, however I'm pretty sure that /g in list context copies the string once, wheras /g in scalar context doesn't copy it at all. The latter I know because i "fixed" it in 5.9.5 and then had to back out the fix because it caused an unacceptable slowdown. However as far as I know you were correct, using capturing parens will cause a copy of the full string. Ill try to follow up with more details from the code when I have more time. --- $world=~s/war/peace/g	[reply]
Re^6: Can we make $& better? (need) by tye (Sage) on Sep 12, 2007 at 20:49 UTC


There's more than one way to do things
	PerlMonks