zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: trying to make things a bit faster...
Date: Thu, 10 Jun 1999 17:00:36 +0200 (MET DST)	[thread overview]
Message-ID: <199906101500.RAA25305@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Thu, 10 Jun 1999 11:27:02 +0200


Peter Stephenson wrote:

> [ about p-mem-1 ]
> 
> I had this same idea.  I also found out it didn't make that much
> difference.  Actually, it wasn't quite the same:  it also skipped heaps
> which had less than a small amount of memory (16 or 32 bytes or something)
> left.  But it still didn't seem to make much difference.

But since it's really quite safe, why shouldn't we...

> [ about p-mem-2 ]
> 
> I only use the zsh memory routines on one machine, so I can't test this all
> that well.  (I'm still worried something nasty may be happening here with
> --enable-lfs, too, but in a compiler-dependent way.)

I've been testing most of these patches with some heavy uses of the
new completion system. In some cases it reduced the number of brk()s and 
sbrk()s from several hundred to less than fifty.
The sizes of the limits may be a bit high, but zsh can get really
hungry for memory.

> 
> > p-exec-1
> >   Several things:
> 
> I think we just have to put all this in and try it.

The ones in p-exec are all quite safe, btw.

> [ about p-exec-2 ]
> 
> I put in a DPUTS at the end of simplifyright() and it doesn't seem to get
> triggered for me either, so far.  I thought it was for really simple
> commands, like a single command given on the command line?  But they same
> to arrive with l->right null anyway.  There's no other case where
> simplification matters so much, so I suggest we just delete it.

Yes, I just didn't dare to do that without asking first.

> ...
> 
> It could be really ancient pfalstad stuff where he wanted to track how
> things we getting executed.  They're all cases where that seems to be the
> only possible use.

Again, yes. In the calling functions the modified structures are not
used again and when the trees were correctly duplicated, they are
never used again.

Bye
 Sven

diff -u os/exec.c Src/exec.c
--- os/exec.c	Tue Jun  8 15:23:06 1999
+++ Src/exec.c	Thu Jun 10 16:48:16 1999
@@ -717,7 +717,6 @@
 	/* Reset donetrap:  this ensures that a trap is only *
 	 * called once for each sublist that fails.          */
 	donetrap = 0;
-	simplifyright(list);
 	slist = list->left;
 
 	/* Loop through code followed by &&, ||, or end of sublist. */
diff -u os/text.c Src/text.c
--- os/text.c	Tue Jun  8 15:23:10 1999
+++ Src/text.c	Thu Jun 10 16:49:38 1999
@@ -169,7 +169,6 @@
 	    if (_List(n)->type & Z_DISOWN)
 		taddstr("|");
 	}
-	simplifyright(_List(n));
 	if (_List(n)->right) {
 	    if (tnewlins)
 		taddnl();
diff -u os/utils.c Src/utils.c
--- os/utils.c	Tue Jun  8 15:23:10 1999
+++ Src/utils.c	Thu Jun 10 16:48:07 1999
@@ -2075,30 +2075,6 @@
     return 0;
 }
 
-/* see if the right side of a list is trivial */
-
-/**/
-void
-simplifyright(List l)
-{
-    Cmd c;
-
-    /*---- when can this be useful? */
-
-    if (l == &dummy_list || !l->right)
-	return;
-    if (l->right->right || l->right->left->right ||
-	l->right->left->flags || l->right->left->left->right ||
-	l->left->flags)
-	return;
-    c = l->left->left->left;
-    if (c->type != SIMPLE || (c->args && nonempty(c->args)) ||
-	(c->redir && nonempty(c->redir)) || (c->vars && nonempty(c->vars)))
-	return;
-    l->right = NULL;
-    return;
-}
-
 /* the ztypes table */
 
 /**/

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~1999-06-10 15:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-06-10 15:00 Sven Wischnowsky [this message]
  -- strict thread matches above, loose matches on Subject: below --
1999-06-08 13:35 Sven Wischnowsky
1999-06-10  9:27 ` Peter Stephenson

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=199906101500.RAA25305@beta.informatik.hu-berlin.de \
    --to=wischnow@informatik.hu-berlin.de \
    --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).