[ On Sunday, March 18, 2001 at 14:22:29 (+0100), wojtek@wojtek.from.pl wrote: ]
> Subject: Re: why /bin and /sbin static
>
> first measurements:
> 
> booting (from pressing enter on boot command to seeing login:) on my
> 486/66 notebook with 8MB RAM and 850MB disk.
> 
> with static /bin and /sbin: 62 seconds. without: 53 seconds.

That's not really very interesting or surprising given your test
environment.

Which exact kernel version are you running?

What's the raw speed on your disk?

How much swap space is used during this process?

I suspect that if you have a decently fast disk and enough RAM not to
need any swap space for this normal operation, then you won't be able to
notice any difference in boot times.  I suspect you do have almost
enough RAM (though the real measurements of paging/swapping statistics
shown with "vmstat -s" will tell for sure), but a 486/66 laptop with
even an 850MB disk is likely to have an extremely slow disk.  I.e. try
the same test on a proper server hardware platform that's designed to
run as a general purpose multi-user Unix system.

Note also that *BSD (i.e. SunOS-4) shared libraries are not really
shared libraries -- they're dynamically loaded and linked libraries.
They are "shared" only in the exact same sense that the text sections of
statically linked binaries are also always shared too.

If you really want to get performance out of "shared" libraries then you
have to make them into true shared libraries that are loaded by the
kernel only once at boot time (eg. like AT&T UNIX System V shared
libraries work).  Otherwise you have to run ld.so and open and run-time
link each dynamic library before you can start any non-static binary,
and that has its own costs that start to add up.

> there are big visual difference when using /bin and /sbin commands
> especially ls,ps,df and top when system is loaded and swapping - they 
> starts about 2 times faster.

Ah -- notice what you said:  "when the system is loaded and swapping".

Although many people work with such over-loaded systems regularly
(myself sometimes included), it is very important to note that even with
virtual memory paging Unix and Unix-like systems were not designed to
run normally in situations where there is great contention for memory
space.  Swapping and paging are schemes invented only for eliminating
contention in situations where it is stupid and unnecessary, and for
allowing you to squeak by during occasional periods of extreme
contention.  If you try to run a system that's constantly under extreme
contention for memory space then you get what you ask for -- slowness.

Finally note that the sharing of text segments in static binaries really
only starts to pay back in a system where multiple instances of such
binaries are (almost) continuously running (eg. in a true general
purpose multi-user system).  If you get 10 people logged in and each
individually running "make build" or some similar intensive scripted job
that runs many instances of the same programs then you'll find that
starting new instances of regularly used and always running statically
linked binaries (eg. /bin/sh) is suddenly faster than starting some new
as-yet unused dynamically linked binary which cause ld.so to run and
which doesn't already have its text segment loaded and thus needs to be
fully read in from disk anew.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>