in reply to Re^4: Impact of special variables on regex match performance
in thread Impact of special variables on regex match performance

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."

  1. 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).
  2. 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.
  3. 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.

  • Comment on Re^5: Impact of special variables on regex match performance

Replies are listed 'Best First'.
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]

In Section Seekers of Perl Wisdom