40% slowdown with dynamic /bin/sh

[M. Warner Losh]

In message: <20031126144357.GK15294 at wombat.localnet>
            Michael Edenfield <kutulu at kutulu.org> writes:
: time make -j 4 buildworld

Hmmm, more jobs.

: They were on a single CPU Athlon 500 with 320MB of RAM.

320MB is not enough RAM not to swap.

I did some preliminary testing last night (which I lost due to a
crash) that showed that a simple 'make buildworld' slowed down 1-2%
depending on how many times I ran them.

However, make -s buildworld (with or without -j 4 on my dual athlon)
was faster than a normal buildworld, but the dynamic /bin/sh was more
like 5-7% slower.  The difference here is that there are fewer context
switches (and I guess less chance for parallelization).

In all make buildworld, the number of page faults was 10x for the
dynamic case than for the static case.

However, having said that, I think everybody realizes the following:

	1) Dynamic linking is slower.
	2) Speed improvements in this area are possible, as
	   demonstrated by other projects.
	3) PIC code is slower than non-PIC code, in general, and also
	   gcc runs about 5-10% slower depending on if you are running
	   out of a shared library or a static one.  shared libraries
	   must use PIC code (at this time).
	4) People like to complain.

Warner

P.S.  One interesting note: /bin/sh when linked statically with
libedit and libncurses but dynamically with libc runs about 10% slower
for my /usr/bin/true/true tests than when all three are dynamically
linked.  So it seems that not all dynamic linking is bad for
performance.