From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19197 invoked from network); 31 Aug 1999 09:56:30 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Aug 1999 09:56:30 -0000 Received: (qmail 1675 invoked by alias); 31 Aug 1999 08:43:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7565 Received: (qmail 1667 invoked from network); 31 Aug 1999 08:43:47 -0000 Date: Tue, 31 Aug 1999 10:22:20 +0200 (MET DST) Message-Id: <199908310822.KAA27325@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Mon, 30 Aug 1999 18:00:22 +0200 Subject: Re: 6-pws-2 Peter Stephenson wrote: > - I haven't looked at the speed of the new pattern matching code. If case > statements with *only* simple strings are slower, there's not much I can > do since it's already optimised to a strcmp(), though I think I can speed > up the string-building loop in patcompatom(). In other cases I can think > of a few tweaks. I think we could 1) come back to my old suggestion to optimise some common patterns (like *str, str*, *str*, s1|s2|s3) in the same way non-pattern strings are already optimised 2) probably add caches for parsed patterns (e.g. give patcompile() an optional pointer to a patcache struct which would contain the strings and compiled pattern of the last few patterns used at the call site and make patcompile() first look there) 3) store compiled patterns in the execution tree (for now I'm only thinking about `case', `[[ .. = .. ]]' and `[[ .. != .. ]]' if the patterns don't need to be singsub()ed, which could be checked at parse time) I haven't tried any of these so I'm not sure if they are worthwhile and easy (and small) enough to implement. Just some thoughts. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de