Actually, I don't see how $regsubex would be much less performant than the solution suggested. What's wrong with regular expressions?
Nothing's wrong with regexes. Besides that they're often not used in situations where they could perform better, and that they're used in as many situations where they don't. Your example belongs to the latter category - it will slow things down noticeably.
I'm not talking about some percent, but, in this example, aprox. the factor 7:
alias regex_example {
var %t = a b c d, %r = /([^ ]+)(?:[ ]+)?/g, %n = 1, %s = $ticks
while (%n <= 20000) {
noop $regsubex(%t,%r,$iif(\t == c,\n))
inc %n
}
echo -ag $calc($ticks - %s)
}
alias findtok_example {
var %t = a b c d, %n = 1, %s = $ticks
while (%n <= 20000) {
noop $findtok(%t,$matchtok(%t,c,1,32),32)
inc %n
}
echo -ag $calc($ticks - %s)
} $findtok($matchtok()) is the superior method for this case, and the OP suggested a further improvement only.
That aside, do you expect average scripters to create a new expression for every new separating char (and so forth)?
I don't see any use for expressions here - besides drawing the attention off the initial suggestion. What's all this defitism about?
I believe what he currently has there "looks ludicruous in terms of readability, script size and performance"
I try to discuss the suggestion in general, not the particular environment it descended from. Even if the given example code may be improved (like virtually every script, including thine and mine), the suggestion stands valid in itself.
He is using $findtok for the very end of finding not the token itslf, but its position in the string.
I don't quite think $poscs would work for his case.
Nobody suggested to use it. Are you possibly mishearing on purpose?
... which might well increase performance..
versus what? something like this, which probably "looks ludicruous in terms of ...performance"?
Nope, versus a nested $*tok-construction. As the initial poster demonstrated in the initial post, and to which I added another example. To reshape the particular, exemplary situation with a different approach (no $matchtok-situation at all) does not add any new facet to the discussion of the feature suggestion, sorry.
