zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Zoltan Hidvegi <hzoli@cs.elte.hu>,
	zsh-workers@math.gatech.edu (Zsh hacking and development)
Subject: Re: The speed of zsh
Date: Sat, 24 Aug 1996 14:15:41 -0700	[thread overview]
Message-ID: <960824141541.ZM453@candle.brasslantern.com> (raw)
In-Reply-To: Zoltan Hidvegi <hzoli@cs.elte.hu> "The speed of zsh" (Aug 24,  9:59pm)

On Aug 24,  9:59pm, Zoltan Hidvegi wrote:
} Subject: The speed of zsh
}
} Somehow ksh spawns external commands twice as fast as zsh.

I suspect it has something to do with zsh's use of pipes for synchronizing
parent and child processes; the zsh parent doesn't do anything until the
child finishes its entersubsh() and closes the pipe.  Ksh probably doesn't
create the pipe in the first place.

It also occurs to me that with child_block()/child_unblock() in use, zsh
probably doesn't *need* the pipe-based synchronization any longer.  Take
it out and see what happens.

} The patch below improves zsh preformance by 10-15%.  An other 10% speed
} improvement would be possible by avoiding the
} child_block()/child_unblock() calls whenever possible (other shells do not
} use any system calls while executing builtin-only scritpts).

I think I said before that we could avoid those if we aren't going to fork
and if the job table is empty.  Maybe they're expensive enough to be worth
the extra test.  On what do you base the 10% figure?

(I'm reasonably sure that with no forks and nothing in the job table, zsh
needs neither the signal blocks nor the pipe sync.)

}   %   cumulative   self              self     total           
}  time   seconds   seconds    calls  ms/call  ms/call  name    
}   4.60    159.35    15.87   899991     0.02     0.04  paramsubst
}   3.96    173.02    13.67 20300232     0.00     0.00  halloc
}   1.58    227.07     5.46 15000174     0.00     0.00  hcalloc

Wow.  That's an awful lot of allocations (no wonder the heap makes so much
difference to zsh's speed), and paramsubst() is pretty expensive per call.

-- 
Bart Schaefer                             Brass Lantern Enterprises
http://www.well.com/user/barts            http://www.nbn.com/people/lantern

New male in /home/schaefer:
>N  2 Justin William Schaefer  Sat May 11 03:43  53/4040  "Happy Birthday"


  reply	other threads:[~1996-08-24 21:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-08-24 19:59 Zoltan Hidvegi
1996-08-24 21:15 ` Bart Schaefer [this message]
1996-08-25  0:12   ` Zoltan Hidvegi
1996-08-25 14:25   ` Zoltan Hidvegi
1996-08-25 16:22     ` Bart Schaefer

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=960824141541.ZM453@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=hzoli@cs.elte.hu \
    --cc=schaefer@nbn.com \
    --cc=zsh-workers@math.gatech.edu \
    /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).