| : 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^)

Eduardo