40% slowdown with dynamic /bin/sh

Gordon Tetlow gordont at gnf.org
Mon Nov 24 22:30:51 PST 2003

On Mon, Nov 24, 2003 at 08:55:31PM -0500, Andrew Gallatin wrote:
> Daniel O'Connor writes:
>  > Why didn't you pipe up when this was discussed _long_ ago?
> In the orginal thread, there was an agreement that the performance
> would be measured BEFORE the default was changed, and the default
> would only be changed if there was no measurable performance impact.
> I believe sam@ asked for this.  As far as I know, performance
> measurments were never done.  Instead, the switch was thrown just
> before the code freeze.

That's not true. I was asked to present numbers so we could make a
determination as to what the impact was. It was never said that it
would only be the default iff there was no performance impact.

FWIW, I did find that the boot process took a performance hit, I
also found that the average worldstone did not increase appreciably
(ie, less than 1%). I took these numbers to re@ when I was asked to
flip the dynamic switch and the feeling was that the overhead was
worth the tradeoff for functionality.

Finally, I must ask if anyone has evidence that this has slowed down
anything other than microbenchmarks? My point of view was it did
slow down the boot, but so did rcNG and no one seemed to mind about
that. Also, you don't write time-sensitive applications in shell
so the dynamic link overhead is not noticed there. People asked me
about the affect on periodic. My response is why do you care if your
periodic took 1 extra second to run (on the outside) due to dynamic
linking overhead. It's just crazy.

In summary, I have yet to see a compelling arguement to consider
backing out the dynamic linking changes I've put in. I've read all of
the messages in all of the 3+ huge threads and I'm still as resolved
today as I was when I made the commit. Frankly, I'm surprised people
didn't yell at me when I massively restructured the tree to put
libraries in /lib. Turning on dynamic linking was the most minor part
from the architectural point of view but is getting the most vitriol.
How typical.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20031124/3f1480a6/attachment.bin

More information about the freebsd-current mailing list