>/home/test001/ksh93/on_build002_m1/test1/proto/root_i386/lib/libcmd.so.1 >/lib/libcmd.so.1 >-rwxr-xr-x 1 test001 users 186060 Apr 26 22:24 >/home/test001/ksh93/on_build002_m1/test1/proto/root_i386/lib/libcmd.so.1 >-rwxr-xr-x 1 root bin 20840 Jan 23 2005 /lib/libcmd.so.1
And size? size /lib/libcmd.so 2190 + 404 + 4 = 2598 "Size is what matters". Not so much the "text" as well as the "data" as the data is unshared. >Startup time is AFAIK not really important in this case as libcmd is >always loaded in a multiuser system since a bunch of deamon processes >use it (for example /usr/sbin/in.telnetd). And /usr/bin/ksh is also >loaded very early at startup during the boot process so both are loaded >and fixed in memory by their consumers. There's always additional relocation needed for a shared library and processing. >The size of unshared data did not really grow much thanks to -xstrconst >which puts the string literals into shared read-only sections and >therefore no longer account for unshared data. >3. The following applications in /usr/bin/ and /usr/sbin/ use >/lib/libcmd.so.1 (the list is incomplete as there are AFAIK both >libraries and applications outside /usr/bin/, /usr/sbin/ and even >outside OS/Net (such as dtlogin etc.)): >Thanks to that list libcmd.so.1 is more or less guranteed to be loaded >and locked in memory in a multiuser system So what's the data/bss. >I agree, however we're talking about three new libraries plus some new >functions in libcmd. It is really not that bad as Mozilla with all it's >modules and ever-changing API, also the size is much smaller (42MB >statically linked Mozilla Seamonkey vs. ~~1.8MB statically linked ksh93 >(debug; the stripped dynamically linked version of ksh93 is just >9k(!!))). Sure; but as the man said "adding a few cycles here cannot be measured (except when you do it a 1000 times)".
