Subject: Re: RFC: migration to a fully dynamically linked system
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 12/21/2001 19:27:46
| : Besides, if static copies are noticeably faster, then why would I (as a
| : rhetorical virtual hoster of masses of websites, for example) want to
| : take a performance hit just to save a few megabytes of RAM?
| Depends on how you define "noticeably faster" here. If you have a lot of
| memory (which you imply here), the needed pages of libc.so and ld.so should
| be in-core, so the only startup overhead is linking perhaps a dozen symbols.
| I'd be interested to see benchmarks on this....
It's a lot more than a dozen symbols for anything other than a trivial
`hello world' program.
| The argument doesn't hold up well, given the fact that only /bin and /sbin
| are static. If you want "static binary speed increases", then you can
| simply rebuild the whole system yourself statically. You can do it with one
| mk.conf switch: "MKPIC=no". 8-)
If you really want to take advantage of the "static binary speed increases"
you really want to crunchgen all of /bin, /sbin, /usr/bin, /usr/sbin, and
some of /usr/libexec into one huge binary so everything is always memory
resident (plus you get the disk and memory saving of dynamic linking too).
When ya gonna add a "MKCRUNCHGEN=yes" flag 8^)