Subject: Re: ksh bugs and behaviour questions
To: David Laight <firstname.lastname@example.org>
From: Roland Dowdeswell <email@example.com>
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. 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.
 Message-Id: <20011230235244.72211DF8@mabelode.imrryr.org>
Roland Dowdeswell http://www.Imrryr.ORG/~elric/