Subject: Re: ksh bugs and behaviour questions
To: David Laight <david@l8s.co.uk>
From: Roland Dowdeswell <elric@imrryr.org>
List: tech-userlevel
Date: 01/25/2003 16:00:24
On 1043522618 seconds since the Beginning of the UNIX epoch
David Laight wrote:
>

>I'm surpised there is that much difference!
>Trully odd things must be going on in ksh (I don't have bash).

Well, yes and no.  We just hacked /bin/sh to use vfork(2) rather
than fork(2) based on this speedup.  So, ksh which still uses
fork(2) is going to be a lot slower.

>$ time sh -c 'for i in $(jot 10000); do /bin/echo -n; done'
>       17.82 real        14.24 user         2.16 sys
>$ time sh -c 'for i in $(jot 10000); do echo -n; done'
>        0.08 real         0.07 user         0.00 sys
>$ time sh -c 'for i in $(jot 10000); do /rescue/echo -n; done'
>        5.96 real         4.44 user         0.63 sys
>$ time ksh -c 'for i in $(jot 10000); do /bin/echo -n; done'
>       29.57 real        20.96 user         7.05 sys
>$ time ksh -c 'for i in $(jot 10000); do echo -n; done'
>        0.21 real         0.07 user         0.02 sys
>$ time ksh -c 'for i in $(jot 10000); do /rescue/echo -n; done'
>       16.68 real        11.55 user         4.13 sys
>
>Clearly all the time in the shell is spent once it knows it has to
>to an exec....

The fork and exec is very expensive.  You'll note that the statically
linked echo performs much better than the dynamically linked one.
I think that I pointed this out as a consideration on the ``dynamic /
thread'' a while back on this list[1].  An email to which no
reply was given, I might add.

It is interesting to note that ksh executing static binaries using
fork(2)/execve(2) seems to be quite similar in time to sh executing
dynamic binaries using vfork(2)/execve(2)---so system performance
is at least being maintained.

[1]	Message-Id: <20011230235244.72211DF8@mabelode.imrryr.org>
	http://mail-index.netbsd.org/tech-userlevel/2001/12/30/0010.html

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/