From: "Bobby D. Bryant" <bdbryant@mail.utexas.edu>
To: Robert Dewar <dewar@merv.cs.nyu.edu>
Subject: Re: Bounded strings yield huge object files.
Date: 1997/08/28
Date: 1997-08-28T00:00:00+00:00 [thread overview]
Message-ID: <34051CFD.5338F33D@mail.utexas.edu> (raw)
In-Reply-To: dewar.872714921@merv
N.B. -- the following takes place in the context of GNAT 3.09 under Red
Hat LINUX 4.2.
Robert Dewar wrote:
> Bobby says
>
> <<Per the appended example, whenever I instantiate a bounded string my
>
> object file grows by about 140Kbytes. This holds whether the
> instantiation is done within a program or as a separate compilation
> unit. (I find that separately compiled instantiations vary in size by
> a
> few thousand bytes depending on the bound that is specified, but those
>
> sizes that I've tried are all in the 140-150K range.)
> >>
>
> Sounds about reasonable for the code of bounded strings with debugging
>
> information included -- of course the majority of this space is the
> debugging information, but you must want it if you are generating it
> (unless you are simply blissfully unaware :-) :-)
Thank you, Robert, for your responses.
While "blissfully unaware" is probably a good description of my relation
to GNAT, Ada, and LINUX all three, I'm not quite convinced that debug
info is the problem. After reading your posts I read up on compiling
for debugging under GNAT, recompiled with % gnatmake -f -g test_2 to
enforce recompilation with debug info, and found that the object file
for the previously mentioned string_80.ads grew from 141708Kb to a
whopping 225924Kb (and, of course, all the other recompiled units'
object files grew as well). Since it grew so much with the -g switch,
I'm fairly confidant that the original file was sans debug info.
Also, regarding your second post, I may need to clarify that the
(non-debug) object file sizes carry over directly to the executable
(that is, an executable program using my string_80 instantiation of the
bounded string stuff is c. 140Kb larger than the same program using
fixed-length strings), so it's not just symbol-table information needed
for consistency checking and linking.
As I say, this isn't killing me, but any further comments (from you or
anyone else) would be appreciated.
Bobby D. Bryant
The University of Texas at Austin
next prev parent reply other threads:[~1997-08-28 0:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3403D2AB.81E37D9C@mail.utexas.edu>
1997-08-27 0:00 ` Bounded strings yield huge object files Robert Dewar
1997-08-28 0:00 ` Bobby D. Bryant [this message]
1997-08-27 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