Re: Substitution ${...///} slows down when certain UTF character occurs

[Bart Schaefer <schaefer@brasslantern.com>]

On Sep 27, 10:13am, Sebastian Gniazdowski wrote:
} Subject: Re: Substitution ${...///} slows down when certain UTF character 
}
} On 26 September 2015 at 22:44, Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Each time pattryrefs() fails to find a match, it increments the area
} > to be searched by one character and then tries the entire pattern
} > match again.  So for a 120000-character string, it's doing a non-
} > matching search 120000 times.
} 
} That's a huge plus that it's still instant fast for strings of that
} length if there is no unlucky unicode character.

It'll get worse if there are partial matches, e.g., if you had 30000
repetitions of "wfei" and scanned for "wfeiwj" there'd be a whole lot
of backtracking.  There are no "w" anywhere in your sample $str so
each of the comparisons is only one equality test.

Still I think the biggest issue is that unmetafication happening too
low down.  Since pattry*() is being called repeatedly with the same two
first arguments (prog and string) it might be possible to cache the
unmetafied string after the first call.