Casper.Dik at Sun.COM wrote: > >/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.
Currently it looks like this: -- snip -- % size /home/test001/ksh93/on_build002_m1/test1/proto/root_i386/lib/libcmd.so.1 /lib/libcmd.so.1 /home/test001/ksh93/on_build002_m1/test1/proto/root_i386/lib/libcmd.so.1: 170999 + 3556 + 10248 = 184803 /lib/libcmd.so.1: 8996 + 505 + 31 = 9532 -- snip -- around ~1.5kb can be saved here via allocating some buffers from the stack (I have a patch for that in the queue which uses C99 features, giving both a performace boost via avoiding the heap allocator and (in other places) reduce the need for static buffers). If there is still someone complaining about the increase in size then I propose to recompile libnsl/libsocket/libc with -xstrconst which will more than compensate the increase in libcmd... :-) [snip] > >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. See above... > >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)". The last time I tested this ksh93q was - for larger scipts - much faster (and ran fewer syscalls) than Solaris /usr/bin/ksh... the question is whether the impact of the merged libcmd to other parts of the system is really that bad... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
