Date: Fri, 15 Feb 2019 05:59:33 +0000
From: m...@netbsd.org
Message-ID: <20190215055933.ga10...@homeworld.netbsd.org>
I have seen Rin's later message so don't need to add my THB1 (about
USD0.03) indicating how bad an idea that would be, but ...
| On Fri, Feb 15, 2019 at 04:43:24AM +0100, Kamil Rytarowski wrote:
| > Recently we were optimizing similarly sh(1).
|
| That wasn't committed.
Has not been yet, and probably will not be, but there are still
measurements being made. The only place it makes a difference is
in situations where lots of new shells are being created, to do very
small tasks (so the ATF tests, and makes that build many objects,
running many small sh commands).
| I'd be really unhappy if much of netbsd base started using dlopen.
So would I - there was a particular reason to test it in this case,
to at least determine if it would make a significant difference
(which was made simpler as it was so easy to do - aside from getting
the Makefile magic correct, the whole thing took about 30 minutes to
write and test, and half that was getting rid of all of my typos...)
It was (and I would suggest, if anything else ever adopts a similar
approach so the cost of some little used functionality - which command
line editing and history are, if you measure by the number of exec's
of /bin/sh which use it, compared with the number that don't - can be
avoided when not needed) such that it could be either linked on the
command line, or dlopen'd at run time, with a trivial Makefile change,
so issues with debugging, etc, could be avoided ... I'd never try
modifying or debugging the sh/libedit interactions using the dlopen()
form. If the two ever visibly act differently, then something was
not done correctly in the implementation.
| I don't think the startup penalty is a required fact of life of using
| dynamic linking,
The size of the penalty might not be (though it was still quite
small, really), but there will always be a difference.
kre
