Idea: static builds
peterjeremy at optushome.com.au
Sun Oct 7 03:22:19 PDT 2007
On 2007-Oct-06 21:20:24 +0300, Diomidis Spinellis <dds at aueb.gr> wrote:
>I can give you quantitative data on the benefits of shared objects. On a
>web server running FreeBSD 6.2 I found 98 shared objects sharing 16,790,901
>bytes of memory through 1,002 mappings.
>Without shared libraries the corresponding binaries would require
>198,815,270 bytes - an order of magnitude more.
Unfortunately, your perl script is overly simplistic and you have
vastly over-estimateed the unshared size. The major inaccuracies are:
- Text segments are shared so multiple instances of the same executable
(eg shells) all share the one copy of memory.
- All of a .so is mapped into every process that references it whereas
a statically linked executable will only link in the required bits of
the corresponding .a. It's extremely unlikely that any executable
uses every function in a library so a static executable will normally
be much smaller than the size of the dynamic executable plus all the
.so's it maps.
- rw mappings are not normally shared
The size differences between static and dynamic linking are not
clearcut and will depend on the process mix. For a server running
multiple copies of a small number of distinct executables, static
linking is likely to use less memory (because the unused parts of the
libraries are not mapped). For a desktop running a single copy of a
variety of different executables - which themselves share large .so's
(eg X applications) then shared libraries are a win.
>These are not just memory savings, but, more importantly on a modern
>system, they contribute to improved locality in the code cache.
It's not clear that a random collection of executables that all
load a common .so will actually have any code locality benefits.
Code locality is a very large can of worms...
Since most of this thread has stressed the advantages of dynamic
loading, it might be worthwhile pointing out some of the benefits
of static linking:
- Static executables start faster because there's no RTLD step
- On some architectures (eg i386) static executables run faster
because PIC code needed in the .so's is less efficient.
- It can be easier to secure the fewer inodes associated with a
static executable than a dynamic one.
To expand on this last point, loading a static /bin/sh accesses 3
inodes. A dynamic /bin/sh on FreeBSD accesses 7 inodes (plus any
dynamically loaded .so's). On Solaris, /bin/sh accesses something
like 20 inodes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20071007/a6ecad01/attachment.pgp
More information about the freebsd-ports