comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Executable File Size Differences
Date: 1996/10/02
Date: 1996-10-02T00:00:00+00:00	[thread overview]
Message-ID: <EACHUS.96Oct2133903@spectre.mitre.org> (raw)
In-Reply-To: 52bq9m$7gn@nr1.ottawa.istar.net


In article <52o1a8$fre@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

  > If Encore Pascal-2 could do it, it _can't_ be hard.

  Uh, it is hard, but for an unexpected reason.  The standard practice
in Ada is to initialize variables when they are declared, if it makes
sense to do so.  So lots of packages create large executables which
are called at elaboration time to initialize a few variables (often
including one which indicates that the package has been elaborated).

  Now many of these variables may never be referenced again, but there
is code in other uncalled procedures that references them.  Worse,
some of the functions will be called to do those initializations.

  So the "tricky" part is in pulling apart object units created by
packages and first creating a full graph tree, then track set/refs on
all variables and find those that are set but never referenced.
Eliminate the code to set those variables and iterate.  You either
need the debug information in the object module or better the compiler
generated AST to do this.  (Of course, you can get a situation where
two units each reference one variable that is set by the other.  Not
erroneous if there is also an initial value.  We thought about
designing in a test for this case, but in practice we designed it out
when encountered.)

  Finally you can pull all the uncalled code and debug information
out.  We had an Ada compiler at Honeywell that did this.  Even more,
it kept track of opportunities to inline subprograms that were
eventually only called once.  But to get the full treatment, you had
to compile--and link--the entire program as a single source file.
Hello World cooked down under 100 bytes, but it took over ten minutes
to do it if you used Text_IO. ;-) (And yes, even on large projects it
was worth it to compile the final release version in this mode.
Unfortunately we ended up with a couple subsystems that wouldn't fix
into memory otherwise, so they always had to be compiled this way.)

    Note that with dynamic linking and first reference traps or a
similar mechanism, all the pain goes away, and you can have an
executable for Hello World that is under 50 bytes--in any language.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...




  parent reply	other threads:[~1996-10-02  0:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-09-25  0:00 Executable File Size Differences Robert P. Kuzmicki
1996-09-25  0:00 ` Georgi Savov
1996-09-28  0:00   ` Stanley Allen
1996-09-28  0:00     ` Robert Dewar
1996-09-30  0:00     ` Richard A. O'Keefe
1996-10-01  0:00       ` Ken Cowan
1996-10-03  0:00         ` Stanley Allen
1996-10-04  0:00           ` Ada 95 - Performance vs. Pervasiveness (was: Executable File Size Diff Larry Kilgallen
1996-10-02  0:00   ` Robert I. Eachus [this message]
1996-10-06  0:00     ` Executable File Size Differences John Howard
1996-09-28  0:00 ` Simon FitzMaurice
1996-10-02  0:00 ` Jon S Anthony
1996-10-11  0:00 ` Robert I. Eachus
  -- strict thread matches above, loose matches on Subject: below --
1996-09-28  0:00 Robert Dewar
1996-09-28  0:00 ` Tony Picarello
1996-09-29  0:00 tmoran
1996-09-29  0:00 ` Robert Dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox