Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!jarthur!uci-ics!teami125
From: teami125@ics.uci.edu (klefstad 125b team i)
Newsgroups: comp.arch
Subject: Re: Large executables: Where's the space going?
Message-ID: <266B4748.28579@paris.ics.uci.edu>
Date: 5 Jun 90 05:46:48 GMT
Reply-To: teami125@ics.uci.edu (klefstad 125b team i)
Organization: UC Irvine Department of ICS
Lines: 28


With all this talk of 1.3Meg 'xclock' executables, etc., has anyone
done any digging to find exactly what is taking so much space? Obviously,
it's library code, et. al., but which routines? Why? How much data?

It just floors me when a simple executable is that big. I didn't even
think the X libraries were that big! Even every X library I can find,
added all together, are only about 800k. Where's the other 500K?

Also, one issue not yet mentioned in this discussion of 'small'
programming is the impact of sloppy linking. IMHO, a smarter linker
could alleviate much of this 'code bloat'. Obviously, this requires a
higher-level view of an object file than just an array of bytes, which
is difficult with existing C compilers and object module formats. It
also requires the library writers to be more careful in segmenting
their routines so as to not suck in everything else when one routine
is referenced.

A good example of this is Ada-language programs. The simplest of
programs on the Unix system we use here (a Sequent Symmetry running
Verdix Ada) often takes 100K for a 'hello world' program. Much of this
is obviously silly linking and code generation by the compiler.

Even though some of these 'huge executable' problems are lessened with
shared libraries, they really don't make the problem go away. They just
amortize the bloat to every process.

                                           Steve Klein