Just code the equivalent of mine in your method, and benchmark that. It should give a pretty accurate idea. | [reply] |
I created a very simple example that matched some simple times with a few different formats, and benchmarked it using named capture buffers, alternative capture group numbering, and your method with embedded code. The alternative capture method is about 40% faster than the named buffers (so I'm going to be implementing it for at least some of the regular expression matching where the order of the matches stays the same). The embedded code was significantly slower (7x) than the named buffers. It's possible I wasn't doing it as efficiently as possible, but given that:
it appears to be significantly slower
it's listed as an experimental feature
the regular expressions are more complicated
I think that I'll pass on it for the time being. But it was fun to experiment with something new!
| [reply] |
yeah, I figured the sub calls would significantly slow things down.
The use of (?{}) doesn't complicate things. It's use is minimal, and it's use is the same for every subpattern. Using it just shifts code from outside the pattern into the pattern. Specifically, it removes the need to parse the returned values a second time in order to get numbers. However, the use of rc does complicate things.
| [reply]
[d/l]
[select] |