in reply to Re^2: metachar match
in thread metachar match
However does this not mean that the input contents ($test) are scanned twice
Yes, but that doesn't necessarily mean it will be a performance problem. Indeed, it doesn't necessarily mean it will be slower than the other way. Regular expression performance metrics are complicated by backtracking, so if you wanted to know how the performance of one way compares with the performance of another way, you'd have to actually test them both. Personally, I've always felt that if you have to do benchmarks to figure out which way is faster, then it doesn't actually matter, because both are fast enough. On the other hand, if you test one way of doing something and have noticeable performance problems, then it's worth looking for a faster way. In the absense of noticeable performance problems, though, any optimization you do is premature. In this example, although the entire string is pattern-matched twice, each of the two pattern matches starts with a static substring (opt and set), which will not match at most points in the string. This limits the amount of tracking forward and back through the string that the matching engine will have to do for these matches.
I would recommend starting with the way that makes the code simple and easy to maintain, and then only if there are performance problems, look for ways to improve performance.
Premature optimization is a root of all kinds of evil for which some have strayed from best practices and pierced themselves through with many sorrows. (Apologies to MJD and Paul.)
|
|---|