zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@ibmth.df.unipi.it>
To: zsh-workers@sunsite.auc.dk
Subject: Re: 6-pws-2
Date: Wed, 01 Sep 1999 10:24:54 +0200	[thread overview]
Message-ID: <9909010824.AA13835@ibmth.df.unipi.it> (raw)
In-Reply-To: "Sven Wischnowsky"'s message of "Tue, 31 Aug 1999 10:22:20 DFT." <199908310822.KAA27325@beta.informatik.hu-berlin.de>

Sven Wischnowsky wrote:
> 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

The trouble here is that this makes the compilation time longer, which is
probably(?) the main bottleneck in cases like case where the pattern is
executed only once (I haven't done any profiling).  str* is already
(supposedly) quite well optimised at run time; in the next set of tweaks,
*str should be, too.  I imagine the pure string optimisation could be
extended to alternatives of pure strings, but I'm not sure of the gain.

> 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)

This ought to be possible, although it'll take a certain amount of
rearranging of structures to be able to flag whether something is a
compiled regexp.  Or maybe a new token could do that.

Bart Schaefer wrote:
> ... but even there it'll mostly help loops, not one-pass sorts of things
> like sourcing init files.

This is true, it won't help the case statements in question.

> The ideal thing might be to "incrementally" compile the pattern; do just
> enough to start discarding strings that can't possibly match, then do a
> bit more upon finding one that might, etc., so parsing and compiling the
> full pattern requires encountering the first successful match (unless it's
> a really intractible pattern).

This will have to live alongside the current structure, for cases where the
pattern is going to be used more than once, so the code could get large and
complicated.  But it could probably be done to some extent.

> Master's theses have been written on less
> interesting problems ... you aren't looking to get a paper out of this,
> are you, Peter?

:-) Well, it looks like I'm giving up physics at the end of the month, so I
need something else to write papers on.  But I just don't know enough of
the theory, anyway.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


  parent reply	other threads:[~1999-09-01  8:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-31  8:22 6-pws-2 Sven Wischnowsky
1999-08-31 11:28 ` 6-pws-2 Andrej Borsenkow
1999-08-31 17:10 ` 6-pws-2 Bart Schaefer
1999-09-01  8:24 ` Peter Stephenson [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-09-01  8:46 6-pws-2 Sven Wischnowsky
1999-08-31 12:38 6-pws-2 Sven Wischnowsky
1999-08-31 16:19 ` 6-pws-2 Tanaka Akira
1999-08-31  8:15 6-pws-2 Sven Wischnowsky
1999-08-31 21:05 ` 6-pws-2 Bart Schaefer
1999-08-30 16:00 6-pws-2 Peter Stephenson
1999-08-30 21:03 ` 6-pws-2 Bart Schaefer
1999-09-01  8:09   ` 6-pws-2 Peter Stephenson
1999-08-31  3:37 ` 6-pws-2 Tanaka Akira
1999-08-31  9:27 ` 6-pws-2 Ollivier Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9909010824.AA13835@ibmth.df.unipi.it \
    --to=pws@ibmth.df.unipi.it \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).