Date: Sun, 3 Jan 1999 12:11:33 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Ollivier Robert <roberto@keltia.freenix.fr> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: shared libs question (overlooked in freebsd-questions) Message-ID: <199901032011.MAA52065@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
:According to Alfred Perlstein:
:> b) save execution time if many seperate programs are being run that
:> use the same libraries (for instance a heavily loaded web site
:> running a lot of CGI programs that share common routines) because
:> of smaller text segment. (really better shared)
:
:Last time we talked about this with John Dyson, he said the opposite.
:FreeBSD can share text between statically linked programs better than with
:dynamically linked ones. So if you have many instance of the same program
:(e.g. shells), make the binary static.
:
:There is a not-so-small price to pay with dynamically linked programs. The
:startup time can be significant and you trash your cache lines when you call a
:library routine because you don't have locality anymore (the "make test"
:phase of Perl5 is about 20%-30% slower when using a dynamic Perl binary).
:
:Code inside a shared lib is PIC code and that is slower as well.
:
:> c) save memory
:
:Yes and no. Yes because the library is loaded only once and no because a
:static binary will have only the functions you need (with dependencies of
:course) whereas a library is mapped entirely.
:--
:Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
John is right. Dynamic libraries work better (save memory) only when
you have lots of *DIFFERENT* programs accessing the same library. If
you have many separately-run instances of a single program, static linking
is generally better.
Remember that dynamic libraries not only require mmap()'ing (which is
cheap but adds a few milliseconds to the startup), it also requires
doing fixups of the library vectors, which causes copy-on-write faults and
is not cheap. Each instance of the same program, if run separately, will
eat more memory.
In the case of a program which fork()'s multiple copies of itself,
static and dynamic binaries will work about the same - at the time of
the fork the fixups have already occured, so the pages are shared
across the N forked copies of the program.
You can easily see this if you have /proc mounted. A 'vnode' object
below indicates a shared segment. A 'default' or 'swap' object
indicates (typically) a private segment. 'default' and 'swap' objects
can only be shared through fork().
With an ELF kernel:
apollo:/tmp# cc hello.c -o hello -static -Wall
apollo:/tmp# ./hello
hello world 52021
^Z
Suspended
apollo:/tmp# cat /proc/52021/map
0x8048000 0x8051000 9 12 4200249 r-x 2 1 0x0 COW NC vnode
0x8051000 0x8052000 1 0 4200253 rw- 1 0 0x2180 COW NNC vnode
0x8052000 0x8053000 1 0 4200251 rw- 2 0 0x180 NCOW NNC default
0x8053000 0x8064000 2 0 4200251 rwx 2 0 0x180 NCOW NNC default
0x28051000 0x28052000 1 0 4200254 rwx 1 0 0x2180 NCOW NNC default
0xefbde000 0xefbfe000 1 0 4200252 rwx 1 0 0x2180 NCOW NNC default
apollo:/tmp# cc hello.c -o hello -Wall
apollo:/tmp# ./hello
hello world 52028
^Z
Suspended
apollo:/tmp# cat /proc/52028/map
0x8048000 0x8049000 1 0 4200303 r-x 1 0 0x0 COW NC vnode
0x8049000 0x804a000 1 0 4200305 rw- 2 0 0x180 NCOW NNC default
0x804a000 0x805b000 2 0 4200305 rwx 2 0 0x180 NCOW NNC default
0x28049000 0x28051000 5 0 4200309 rwx 1 0 0x2180 NCOW NNC default
0x28051000 0x280bd000 51 0 1879718 r-x 27 11 0x4 COW NC vnode
0x280bd000 0x280c2000 5 0 4200310 rwx 1 0 0x2180 COW NNC vnode
0x280c2000 0x280d2000 3 0 4200311 rwx 1 0 0x2180 NCOW NNC default
0x40000000 0x4000e000 10 0 1941346 r-x 27 11 0x4 COW NC vnode
0x4000e000 0x4000f000 1 0 4200308 rw- 1 0 0x2180 COW NNC vnode
0x4000f000 0x40011000 2 0 4200306 rw- 1 0 0x2180 NCOW NNC default
0xefbde000 0xefbfe000 2 0 4200307 rwx 1 0 0x2180 NCOW NNC default
Compiled A.OUT:
apollo:/tmp# cc hello.c -o hello -static -Wall -aout
apollo:/tmp# ./hello
hello world 52042
^Z
Suspended
apollo:/tmp# cat /proc/52042/map
0x1000 0xa000 9 12 4200488 r-x 2 1 0x0 COW NC vnode
0xa000 0xb000 1 0 4200492 rwx 1 0 0x2180 COW NNC vnode
0xb000 0x1d000 3 0 4200491 rwx 1 0 0x2180 NCOW NNC default
0x2000a000 0x2000b000 1 0 4200493 rwx 1 0 0x2180 NCOW NNC default
0xefbde000 0xefbfe000 1 0 4200490 rwx 1 0 0x2180 NCOW NNC default
apollo:/tmp# cc hello.c -o hello -Wall -aout
apollo:/tmp# ./hello
hello world 52049
^Z
Suspended
apollo:/tmp# cat /proc/52049/map
0x1000 0x2000 1 3 4200544 r-x 2 1 0x0 COW NC vnode
0x2000 0x3000 1 0 4200547 rwx 1 0 0x2180 COW NNC vnode
0x3000 0x18000 6 0 4200549 rwx 1 0 0x2180 NCOW NNC default
0x20002000 0x20013000 12 0 2027070 r-x 21 9 0x4 COW NC vnode
0x20013000 0x20014000 1 0 4200548 rwx 2 0 0x2180 COW NNC vnode
0x20014000 0x20015000 1 0 4200548 rwx 2 0 0x2180 COW NNC vnode
0x20015000 0x20017000 2 0 4200550 rwx 1 0 0x2180 NCOW NNC default
0x20019000 0x20085000 72 0 2023214 r-x 20 8 0x4 COW NC vnode
0x20085000 0x20089000 4 0 4200551 rwx 1 0 0x2180 COW NNC vnode
0x20089000 0x20097000 2 0 4200552 rwx 1 0 0x2180 NCOW NNC default
0xefbde000 0xefbfe000 4 0 4200546 rwx 1 0 0x2180 NCOW NNC default
-Matt
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901032011.MAA52065>