Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!ICSI.Berkeley.EDU!stolcke From: stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) Newsgroups: comp.windows.x Subject: Shared libs with X, Frame (Was: Re: Xkernel) Keywords: shared libs, X, Frame maker Message-ID: <1990Dec19.191336.14848@agate.berkeley.edu> Date: 19 Dec 90 19:13:36 GMT References: <1990Dec5.214857.13863@agate.berkeley.edu> <1990Dec14.001146.3131@eng.umd.edu> <80@tdatirv.UUCP> Sender: usenet@agate.berkeley.edu (USENET Administrator) Reply-To: stolcke@ICSI.Berkeley.EDU (Andreas Stolcke) Organization: International Computer Science Institute, Berkeley, CA Lines: 59 In article <80@tdatirv.UUCP>, sarima@tdatirv.UUCP (Stanley Friesen) writes: |> In article <1990Dec14.001146.3131@eng.umd.edu> stripes@eng.umd.edu (Joshua Osborne) writes: |> >In article <1990Dec5.214857.13863@agate.berkeley.edu> you write: |> >> ... which are now running SunOS4.1 and have become unbearably slow when |> >> running standalone X (mostly through the dynamic linking business, |> >> we believe). |> |> >Compile a staticly linked set of X programs, your already poor throughput will |> >become really *really* poor (on a 4Meg system at least). |> First, let me explain a bit what I meant in my original posting about 4.1 being slower that 3.5 with X. Dynamic libraries buy you reduced total virtual memory requirement, thereby reducing swapping and speeding up things. Actually I checked that using pstat -s, and it turns out that my standard initial X desktop uses 9600k under 3.5, but only 7144k under 4.1. Add emacs and latex and the gap increases to 14872k vs. 10904. In fact with swap space being as tight as it is around here, some people could almost do nothing with their machines once X was started, because there wasn't even enough space left for a simple latex run. Obviously this problem was partly taken care of in 4.1. So far, so good. Now the flip side of shared libs is that they have to be linked dynamically, i.e. on every invocation of a program /usr/lib/ld.so is called to resolve references to dynamic libs. The delay this causes on a 3/50 is non-negligible (it probably is on a Sparc), but probably won't be too bad for usual interactive work. Also, most commands use only the shared C lib, so there is not too much dynamic linking to be done. During the startup phase of X, however, a flury of background jobs all requiring dynamic linking against the X libs are created, and this is simply too much for the poor little 3/50s. Again, using my standard X environment, it takes < 2mins to start up under 3.5, but almost 4mins under 4.1. So I should have been more precise in talking about `slowness', making it clear I was talking about startup time. |> I would like to emphasize the truth of this. I, too, believed that the |> dynamic linkng was a speed problem, until we got FrameMaker 2.1X from Frame |> Technologies. That monster is statically linked. True, shelltool takes a |> longish time to *start*, but once it is running it is quite good. Maker |> on the other hand starts slow and then generates a paging fit whenever I |> switch from one activity to another. Talk about *sloooow*! (Frame Technology |> are you listening? - at *least* make xlib and libc dynamic linking!) |> The reason for Frame's using statically linked binaries is probably that they want to prevent against someone getting smart and breaking their license control scheme by `patching' libc.so. I'm not familiar with the details of their implementation, but suppose it gets the host id to match it against a built-in licence. It would be easy to fudge the relevant system calls to always provide the `right' host id... I don't see a reason to not use shared X libs, though, and that would be a *big* win in terms of memory efficiency. Maybe they don't every customer to have a shared version of X libs, but then they could make it an option. -- Andreas Stolcke International Computer Science Institute stolcke@icsi.Berkeley.EDU 1957 Center St., Suite 600, Berkeley, CA 94704 (415) 642-4274 ext. 126