:>
:> So the difference is 38 pages of memory = 152KB per instance.
:> That's fairly significant on a multi-user system that might have
:> several hundred csh's running. I specifically compile certain
:> non-forked binaries on my system static precisely to reduce their
:> memory footprint.
:
:Remember that those 38 pages may be completely shared in a dynamic
:library, leading to memory usage reductions. What is true is that the
:startup time for dynamic binaries is most likely slower.
No. Those are zero-fill and COW faults. They aren't shared if the
program is separately exec'd. A program like sendmail and apache,
which fork()'s its children, would be able to share that data. Programs
like getty, csh, and sh, which are typically exec'd, cannot share
the zero-fill and COW faults.
:Other (major?) reasons I have heard in favor of dynamically linking
:root:
:a. locale support
:b. nsswitch.conf support
:c. PAM support (maybe this encompasses b.)
:
:Dynamic linking has been said to be the only way to get locale support
:and support for multiple authentication schemes. I don't know if
:dynamic linking is absolutely necessary to supports these things from a
:technical standpoint, but it would be nice to know (does anyone know?).
:
:For embedded devices, a single crunchgened binary would probably
:smaller anyway e.g. PicoBSD and installation floppies (?).
Possibly. I don't know enough about the issue though I don't see
why it would be the case. the Dynamic link loader ought to work
either way.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
