On 2007-Oct-06 21:20:24 +0300, Diomidis Spinellis <[EMAIL PROTECTED]> 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. -- Peter Jeremy
pgpbTXsWTzcBB.pgp
Description: PGP signature