From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29425 invoked by alias); 28 Sep 2015 19:28:46 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36682 Received: (qmail 10681 invoked from network); 28 Sep 2015 19:28:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Originating-IP: [80.3.228.158] X-Spam: 0 X-Authority: v=2.1 cv=JuUM15MC c=1 sm=1 tr=0 a=P+FLVI8RzFchTbbqTxIDRw==:117 a=P+FLVI8RzFchTbbqTxIDRw==:17 a=NLZqzBF-AAAA:8 a=kj9zAlcOel0A:10 a=hD80L64hAAAA:8 a=FhFgS_QsNzTxYCErpSEA:9 a=CjuIK1q_8ugA:10 Date: Mon, 28 Sep 2015 20:23:12 +0100 From: Peter Stephenson To: Peter Stephenson Cc: zsh-workers@zsh.org Subject: Re: Substitution ${...///} slows down when certain UTF character occurs Message-ID: <20150928202312.6679b38e@ntlworld.com> In-Reply-To: <20150928095142.385a33eb@pwslap01u.europe.root.pri> References: <150926134410.ZM17546@torch.brasslantern.com> <150927091121.ZM25721@torch.brasslantern.com> <20150928095142.385a33eb@pwslap01u.europe.root.pri> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 28 Sep 2015 09:51:42 +0100 Peter Stephenson wrote: > 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. This does the back-end work, with a patstralloc structure that allows you to maintain information about an unmetafied string over calls to pattrylen() and pattryrefs(). It uses this version of the optimisation > 4. Have both metafied and unmetafied variants for the pattern when using > a pure string, but only produce, and cache, the unmetafied version when > needed for comparison. This is more effective than caching the trial > string because the pattern is only compiled once for many uses of it --- > we only lose out here if somebody is looping over a pattern (not just a > trial string as in the glob code) many times i.e. either redoing > patcompile() or using a pre-compiled pattern, and the latter isn't all that > common in the code (I'm not sure where it does happen if it does). > This seems to push the inefficiency out of inner loops to a frequency > where it's probably not a noticeable factor any more. with the cached unmetafied pure string, where needed, within the patstralloc structure. However, the new code here to handle the unmetafied case isn't tested yet as there's nothing using the new interface, which is the next step. pws