Very Computer

Elaboration:  On my Sparstation-5 SunOS5.3 system, /sbin/sh starts up
significantly faster than /bin/sh (aka /usr/bin/sh), presumably because
it is statically linked.
/bin/echo is also linked dynamically, hence it's slow, too.

Question: Is there a good reason not to link /bin/sh to /sbin/sh on
SunOS5.x systems?  It should make the whole system zippier, given the
pervasive use of /bin/sh for scripts and even lots of little utilities
in /bin, such as /bin/true etc.
Assuming /sbin/sh is functionally identical to /bin/sh, the only reason
against it I can see is that /bin/sh wouldn't be affected by patches
to the shared libc, and possibly to /bin/sh itself.
On SunOS4.x systems /bin/sh is already a static binary.

I noticed this as I was running a litte benchmark for a local version of
make.  The makefile used looks like

all:    foo1 foo2 ...
foo1 foo2 .... :

with 1000 foo* targets.

The semicolon forces make to hand the command to /bin/sh, and the whole thing
takes
        20.26u 39.79s 1:22.86 72.4%             (1)

When I set SHELL=/sbin/sh this reduces to

        6.25u 13.63s 0:34.83 57.0%              (2)

almost a threefold speedup (and that includes the fixed overhead of
reading the makefile etc.)

If I replace the command line with

make exec's it directly, without going through /bin/sh.  This gives

        11.50u 24.98s 0:56.11 65.0%             (3)

and is thus slower than the built-in echo from /sbin/sh.
Finally, when execing the /sbin/sh-echo script instead we're roughly
back to the speed of (2) above, as expected:

        6.51u 14.69s 0:32.94 64.3%

BTW, you get basically the same effect with Sun's make, except it
has more overhead in all of these cases.

BTW2, SunOS4.1.3 gives virtually identical times (on the same hardware),
modulo the fact that /bin/sh and /sbin/sh are identical.

--


1947 Center St., Suite 600, Berkeley, CA 94704  (510) 642-4274 ext. 126