Ok point taken. However does this not mean that the input contents ($test) are scanned twice ?. In my example it's a small input but in reality it may be considerably larger (granted I should have pointed that out). | [reply] |
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.)
Sanity? Oh, yeah, I've got all kinds of sanity. In fact, I've developed whole new kinds of sanity. Why, I've got so much sanity it's driving me crazy.
| [reply] |