Re: Possible slight speedup to non-interactive /bin/sh startup

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 11 Feb 2019 18:36:16 +0700
    From:        Robert Elz <kre%munnari.OZ.AU@localhost>
    Message-ID:  <26894.1549884976%jinx.noi.kre.to@localhost>

  | It is really only a fairly small difference, 170 us isn't big
  | by anyone's measure...

As another data point, I ran my stupid 10000 execs of "sh -c :"
loop using /rescue/sh (static linking) in the same environment
and that runs about 37% faster than a standard /bin/sh and 27%
faster than the version without libedit or libtermlib linked
initially.

That is, doing ld.so at all, with just libc, is costing about 230 us
for /bin/sh (running the smallest possible sh script - so this includes
the actual cost of relocating the libc symbols that get used to do
that, which is probably more of them than you might guess.)

One assumes that a (much smaller) staticly linked /bin/sh would be
slightly faster still - but doing that isn't really what I think we
should be doing (that option is open to anyone who wants it by
just building a static root filesys) as it loses the ability to
get libc bug fixes by just updating libc.so, and also would consume
a little more overall ram as the libc in sh wouldn't be shared
with anything else.

kre