john@acorn.co.uk (John Bowler) (01/04/89)
Johan Widen's posting about making a shareable libX11 for SunOS version 4 prompts me to make some comments about shared libraries and X11. He says:- > Linking with the shared version of libX11 can result in substantial savings > of disk space, and you may also see savings in memory use if like me you > tend to have a lot of clients hanging around. > > It's a pity that it should be so difficult to turn libXt into a shared library. We decided we had to use shared libraries for precisely these reasons (we have a UNIX system on a 50MByte hard disc, plus we only have around 64 vm pages on the hardware - so any run time memory saving is very important). The results (in performance and disc saving) are quite spectacular. Applications which were linked with libX11.a and libXt.a and occupied 200k-300k of text space have decreased to under 100k in many cases. X11 systems show gains from shared libraries particularly well because several different applications are running concurrently but executing identical blocks of code. The fact that the applications are different means that the text sharing in BSD43 does not actually help - even though most of the code is the same. The fact that the applications run concurrently means that acceptable performance depends on having many applications in physical memory at the same time. For example consider typing characters into a csh - the server, xterm, the csh itself and the window manager are probably all involved - code sharing between the xterm and the window manager can therfore be a significant benefit. All this is quite obvious. Interesting problems are, however, posed by the way Xt is implemented. In the first place if you use one part of Xt you use it all (with one or two exceptions). The object oriented structure means that a reference to a higher level widget drags in all its ancestors, including their associated code, even though some parts of that code may not be used. The advantage of having Xt in a library is thus considerably reduced. The advantage of a shared library is correspondingly increased unless the page size of the underlying architecture is sufficiently small to cause unused code never to be loaded. On the other hand a very substantial proportion of the semantics of Xt are represented in data rather than in text. Roughly one third of the total size of Xt is data in our current shared libraries - compare this with the 3% of our shared libc which is data. Since the data cannot be shared this reduces the utility of shared libraries. I see these two attributes of the Toolkit Intrinsics as major disadvantages. Xt plus suitable widget libraries certainly provide a fast and easy way of developing new applications, but the resultant programs tend to be very large. Even with shared libraries the large amount of data makes Xt far from ideal for the development of small, frequently used, utility applications for use on machines with limited resources. John Bowler, Acorn Computers Ltd jbowler@acorn.co.uk