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

[Peter Stephenson <p.stephenson@samsung.com>]

On Sun, 27 Sep 2015 09:11:21 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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.

It would be good to optimise the cases where the calling code in glob.c
(for the parameter-style operators only) matches at different places along
the string, too, which means unmetafying at a higher level.  That's
quite a lot of work in the glob.c code, though, because we'll need to
deal with length and switch the multibyte handlers to umetafied.

I think a reasonable strategy would be to change the call sequence for
pattrylen() and pattryrefs(), which are the key ones, to pass in an
optional unmatefied string; some of the remaining calls in glob.c could
be premoted to pattrylen which is a strict superset of pattry.  That
would leave pattry() untouched for the majority of cases doing one-off
matching.

Ideally we only want to pass in either a metafied or unmetafied string.
I don't know off the top of my head how much work it is to fix up the
PAT_PURES optimisation where we've got an already unmetafied string but
it shouldn't be too much.

pws