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>