One of the main costs of dynamic linking is making fork much slower. Even on linux statically linked binaries fork a few magnitude orders faster than dynamically linked ones.
The main source of anti-fork FUD turns out to be the alleged 'solution' to a problem that didn't exist until the geniuses at Sun decided dynamic linking was such a wonderful idea. On linux with ancient hardware one can do hundreds of forks per second without any problems, it works great for werc[1], and it is amusing to see people inventing hacks like fcgi and writing pthreaded web servers to avoid as much as one fork call per request, when making hundreds of them is a non-issue. An example of how one mistake in systems design(introduction of dynamic linking) leads to even greater mistakes down the road (pthreads, fcgi, all kinds of hacks to avoid fork), and people never steps back to think if the original design decision was really worth it. Peace uriel [1]: http://werc.cat-v.org On Fri, Feb 20, 2009 at 4:41 PM, erik quanstrom <[email protected]> wrote: >> I believe that >> 1) Its too much trouble parsing the output everytime. > > i don't buy that. that takes very little code. since you > have evidently already written the code, the cost > is zero. > > (if you're worried about runtime, i measure parsing > time at 338ns on a core i7 920. cf. attached digestspd.c) > >> 2) Calling some function from an included library will be faster. > > maybe. are you sure that it matters? i measure > base fork/exec latency on a 1.8ghz xeon5000 at 330µs. > (files served from the fileserver, not a ram disk.) > the attached fork.c and nop.c were used to do the > measurement. i measure vac throughput at ~3mb/s > for small files from a brand new venti running from a > ramdisk. the venti was tiny with 5mb isect and 100mb > arenas, and empty. at that rate, 330µs will cost you > 1038 bytes, or 0.3%. > > remember that dynamic linking isn't free. that cost > assumes that dynamic linking is free, and it is not. > > - erik
