The other dynamic linking taxI've already talked about one dynamic linking tax, but here's another one. Presented in illustrated form:
; cat true.c
#include <stdlib.h>
int main(int argc, char **argv)
{
exit(0);
}
; cc -o true true.c
; cc -o true-s -static true.c
; diet cc -o true-d true.c
; ls -s true true-d true-s
8 true 4 true-d 388 true-s
; strace ./true >[2=1] | wc -l
21
; strace ./true-s >[2=1] | wc -l
5
; strace ./true-d >[2=1] | wc -l
2
This is on a Fedora Core 2 machine. On a Fedora Core 4 machine the dynamically linked version makes 22 syscalls and the static linked glibc version makes nine.
This makes a difference in execution speed too. The dynamically linked glibc version runs 1.38 to 1.47 times slower than the dietlibc version, and the statically linked version 1.06 times slower. Admittedly this is sort of a micro-benchmark; most real programs do more work than this before exiting. I ran into this while trying to measure the overhead of a program that
I wanted to be as lightweight and fast as feasible. Sidebar: just what's going on with glibc?The statically linked glibc version also calls
This table does not count the initial (Again, this is on a Fedora Core 2 machine. Your mileage will differ
on different glibc versions. On FC4 the static
linked glibc version does a |
These are my WanderingThoughts GettingAround This is part of CSpace, and is written by ChrisSiebenmann. * * * Atom feeds are available; see the bottom of most pages. Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web |