I'm an advocate for shared libraries. With libbz2 the memory savings might not be taken advantage of, by other software, as much as libz, but the idea is the same. While the cpu performance looses 4%, the memory loss of running bzip2 on several instances goes into several hundred percents. Statically linked programs always have better load times than dynamically linked programs, but this can be mostly revovered by prelinking them (see the prelink.txt hint).
Considering the small sizes of bzip2 and libbz2, saving on memory as a trade off for saving the cpu may not be a convincing trade; but its something to consider. The advantages are only seen when two or more programs are using libbz2 at about the same time. robert On December 3, 2005 10:47 am, Ken Moffat wrote: > On Sat, 19 Nov 2005, go moko wrote: > > Hello > > > > Just a question: During the installation of Bzip2, why > > does the book use the bzip2-shared binary, instead of > > the bzip2 binary installed by the 'make install' > > command? The README of Bzip2 indicates that the bzip2 > > binary is better and recommand it. > > > > Regards > > G. Moko > > Sorry for the late reply to this. As far as I can see, the developer > has two reasons for this stated preference - > > (i) the shared program is not tested. Well, maybe somebody ought to fix > the testsuite (attached, but unlike the non-shared version this test > isn't run automatically). But, does anybody else care if bzip2 gets > tested ? > > (ii) the shared version is slower (on platforms like x86 which lack an > adequate number of registers). This doesn't seem compelling to me - if > speed was that important, we'd still be using gcc-2.95.3. > > For decompressing, the difference is not significant. On my duron > (1GHz, but PC100 memory, and a bit underpowered now) I used > both versions of bzip2 with -dc to take gcc-4.0.2.tar.bz2 (on an nfs > mount) and write it to a local file. That box is running an LFS-6.1 > toolchain. Three runs of each, 58 seconds using bzip2, 58 to 61 seconds > with the shared version (variation < 4%). > > If you compress a big dataset, then yes, the differences are more > significant. Using a 186M tarball from a partial system build, with a > sync before each test and two runs of each, user time varied from 3m32 > (non-shared) to 3m52 (shared) which is about 9.5% slower. > > So, if you reguarly compress large files with bzip2 on x86, you might > want to consider using the non-shared version to use a bit less time. > For most people, and for people using fast processors with fast memory, > it probably isn't worth using the non-shared version of bzip2. > > Ken -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
