From: Paul Kranenburg <pk@cs.few.eur.nl>
   Date: Sun, 14 Nov 93 14:35:31 +0100
   Cc: current-users@sun-lamp.cs.berkeley.edu
   Sender: owner-current-users@sun-lamp.cs.berkeley.edu
   Precedence: bulk

   > 10198 root       3    0  936K  644K sleep   0:00  3.30%  1.66% tcsh.dynamic
   > 10196 root      18    0  552K  428K sleep   0:00  0.90%  0.59% tcsh.static

   > The dynamically linked version uses much more memory than the statically
   > linked version (huh?). Or is 'top' just confused by the shared memory
   > pages?

   I can't explain the 400K difference in the 'process size' field.

Probably because you're adding the additional text and data from all
shared libraries and ld.so.

   The increase in `resident' size is perfectly explainable from the
   of the run-time linker actions. ld.so itself is about 70K in size, it uses
   stack space, and it touches the data area of shared libraries all before
   it gets around to calling `_main()'.

Yup.. shared libraries are a win for sharing text pages and saving
disk space, but make things worse when it comes to the data pages.

You have to do some fairly grungy hacks to cut down on the number of
shared data pages you touch at startup:
 - segregate initialized data containing pointers from initialized
data which does not contain pointers (so that ld.so doesn't touch
*all* data pages at startup).
 - put as much read-only shared data into .text as possible.
 - use malloc instead of static buffers in libc so that you don't even
need to allocate VM space for the pages unless the actual libc
routines which use them are called.

					- Bill

------------------------------------------------------------------------------