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

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

    Date:        Mon, 11 Feb 2019 09:05:53 +0000
    From:        maya%netbsd.org@localhost
    Message-ID:  <20190211090553.GA2991%homeworld.netbsd.org@localhost>

  | I feel like we should dig into why it makes a big difference.

It is really only a fairly small difference, 170 us isn't big
by anyone's measure...    But yes, that seems like a worthwhile
project assuming the answer isn't already known, for someone
other than me!

But I'd have guessed that just locating the libraries, which ld.so
always does, so execution fails early if a required library cannot
be found, would account for most of that cost.

Which actually points out another (minor) benefit of this change:
it makes /bin/sh dependent on less of the system existing properly
in order to be able to work, if libedit or libtermlib were to vanish
or something, sh would still work (without line-editing/history).

  | I played with it a bit, and it looks like the biggest difference I got
  | was by setting LC_ALL=C as opposed to LC_ALL=en_US.UTF-8.

I'm surprised that makes much difference, the operations in sh
(which currently has a very limited understanding of character
encoding issues) that would be affected by that are not common
in most cases where sh speed really matters I would have thought
(that might be something that affects autoconf type scripts and
such more though.)

While I am not sure I believe him, and others certainly do not,
but the author of one of the other shells around is fond of
repeating (over and over) that the speed of a shell will drop
by 50% if it does locale (ie; char encoding) properly.  (No,
bash is not that shell, even though it is slow...)

kre