Date: Mon, 11 Feb 2019 18:36:16 +0700
From: Robert Elz <k...@munnari.oz.au>
Message-ID: <26894.1549884...@jinx.noi.kre.to>
| 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
