Re^3: Impact of special variables on regex match performance

I'm sure it's possible to pose a challenge ("real project") in which those variables would be needed... but it's hard to come up with one. Consider:

 $` The text before matching -- In your code, that's $in
 $' The text which comes after the match in an input string -- Alt: Lo
+okarounds
 $& The text of the match itself -- Use captures instead
[download]

As mentioned, the cost (= slowdown) is well documented in the standard regex docs; and in many books, tutorials and nodes devoted to regular expressions.

Concerning your code: given that sub uncomment_one is never explicitly called in what you posted, you may have over-reached in your diligence to follow the guidance ( not exactly "rules ) of this forum. /me suspects that profiling what you show would be informative; certainly, as is, the slowdown using your code is largely caused by the copying which is expensive, as JavaFan points out above.

Comment on Re^3: Impact of special variables on regex match performance Select or Download Code

Replies are listed 'Best First'.
Re^4: Impact of special variables on regex match performance by roubi (Hermit) on Dec 10, 2010 at 00:53 UTC
Concerning your code: given that sub uncomment_one is never explicitly called in what you posted, you may have over-reached in your diligence to follow the guidance ( not exactly "rules ) of this forum. I put that code in a sub on purpose. The performance impact is triggered by the mere presence of those variables in the code, not their actual use as part of the execution of the script. And so there is no need to imagine a situation where those variables would be actually needed, only one where you'd need to load a module that contains those variables in a sub your code doesn't actually call.	[reply]
Re^5: Impact of special variables on regex match performance by ww (Archbishop) on Dec 10, 2010 at 03:21 UTC
Just a couple nodes back you asserted that NOT using the vars "isn't an option;" Then you conceed that you "didn't mean to say that there are no technical alternatives" Now you're offering justification by way of a hypothetical case in which one might "load a module that contains those variables." That suggests you'd better take a look at what's in the module that you might load (and, IMO, any module that uses those needs to be scrutinized very carefully for {other} sub-optimal techniques). Some -- very possibly most -- of the "performance impact is triggered by the mere presence of those variables" but you haven't allocated any of it to the difference between calling a no-op sub (all commented) and a sub with as much as a single operation (one, uncommented). Again, profile it. You are correct, of course, that some..most of the impact is from declaration, but, as noted by numerous respondents, that's well documented. Learning facts like that is part of the reason for reading the docs. UPDATE: Inserted dropped negation, para 1, sentence 1.	[reply]
Re^6: Impact of special variables on regex match performance by roubi (Hermit) on Dec 10, 2010 at 04:12 UTC
Yes, having those variables not seen at compile time isn't an option, for the reason I already gave. My code is but one piece of a bigger project for which I have no control over what modules get loaded or what their content is. I'll admit to a lack of details on my situation but not of consistency in my answers... Again, profile it. Always a good advice. Profiling with NYTProf prior to my original post is how I detected the source of my issue. Learning facts like that is part of the reason for reading the docs Another great piece of advice. I quote perlvar myself in my post so I think I pass :)	[reply]