40% slowdown with dynamic /bin/sh

[M. Warner Losh]

In message: <20031125080155.GC76478 at server.vk2pj.dyndns.org>
            Peter Jeremy <peterjeremy at optushome.com.au> writes:
: On Mon, Nov 24, 2003 at 11:16:07PM -0700, M. Warner Losh wrote:
: >Hmmmm, It looks like the hit is less than 10% in the fork intensive
: >test I just wrote:
: >
: >#!/bin/sh
: >for i in 0 1 2 3 4 5 6 7 8 9; do
: >    for j in 0 1 2 3 4 5 6 7 8 9; do
: >        for k in 0 1 2 3 4 5 6 7 8 9; do
: >             for l in 0 1 2 3 4 5 6 7 8 9; do
: >                 for m in 0 1 2 3 4 5 6 7 8 9; do
: >                      for n in 0 1 2 3 4 5 6 7 8 9; do
: >                        true;
: >done; done; done; done; done; done;
: 
: Unless you've done something wierd to your /bin/sh, "true" is a
: builtin.  This test just to measures the ongoing runtime overhead
: of a dynamic executable (ie PIC code).  Drew's test was measuring
: the startup overhead.

True.  However, I get very similar numbers of I change it to
/usr/bin/true (12% slower).  /bin/sh usually fork+exec things other
/bin/sh.

: >Clearly dynamic is slower, but it is more like 11% slower (10.67%) on
: >the average than 40% slower.  I think this would be a more typical
: >usage pattern.
: 
: You have measured different things.  Drew's test shows that a dynamic
: /bin/sh tahes about 40% longer to start.  Your test shows that once
: started, it runs about 11% slower.  And the 11% slower is _very_
: worrying since it is probably more widely applicable than just /bin/sh.

Dynamically linked prorgrams tend to be a few percent slower than
their static counterparts due to PIC code typically being slower than
non-PIC code.  There's nothing new here.

Clearly there are problems to look into, but it isn't the end of the
world.

Warner