In message: <[EMAIL PROTECTED]>
            Michael Edenfield <[EMAIL PROTECTED]> 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.


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
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to