From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no
	version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cd7d510783cb3f76
X-Google-Attributes: gid103376,public
From: "Tony Picarello" <primate@worldnet.att.net>
Subject: Re: Executable File Size Differences
Date: 1996/09/28
Message-ID: <01bbad5c$f6121fc0$90ea93cf@darkstar.bitsurfer.com>#1/1
X-Deja-AN: 185853339
references: <dewar.843920181@schonberg>
content-type: text/plain; charset=ISO-8859-1
organization: AT&T WorldNet Services
mime-version: 1.0
newsgroups: comp.lang.ada
Date: 1996-09-28T00:00:00+00:00
List-Id: <comp.lang.ada>


I too compiled the simple "Hello World" program using ObjectAda.  The exe
size "Win32 (Intel) Debug" version was 715K.  The exe "Win32 (Intel)
Release" version was 82.5K.

For obvious reasons, building a Debug version brings a lot of extra stuff
into the exe.  Just be sure that your final build is a Release version.  I
think this answers the question of the why the ObjectAda exe is several
hundred Kilobytes larger than the C++ exe.

Regards,
Tony


Robert Dewar <dewar@schonberg.cs.nyu.edu> wrote in article
<dewar.843920181@schonberg>...
> Robert said
> 
> "I tried compiling a simple "Hello World" program with the Thomson
Software's Act
> ivAda for Windows
> and Thomson's new "ObjectAda". The ActivAda version produces a executable
file s
> ize of about 288K.
> ObjectAda produces an exe of about 788K. Microsoft C++ produces an exe of
about
> 10K. Why are the
> executables so substantially different? Are the Ada compilers linking in
alot of
>  excess baggage? I
> have tried various compiler switches, but nothing seems to shrink the exe
file s
> izes.
> 
> Can anyone enlighten me here?"
> 
> (P.S. please keep your posts to 80 characters, really makes life easier!)
> 
> The GNAT executable under OS/2 is 57K, which is smaller but still larger
> than the 10K you see from C. There are two reasons for this. First, it is
> likely that the C is linking against a dynamically shared library which
> is taking up room, but does not show up in the 10K. Second, GANT is
> indeed dragging in quite a bit, including full exception support, full
> support for controlled types, full support for tagged types. In a small
> program this makes for some extra size, but of course this is a fixed
size
> increment, if you make a larger program, it does not get proportionally
> bigger.
> 
> For example, I just wrote a complete preprocessor program for GNAT (toi
be
> included in some future release!) that provides conditional compilation
> capability, and symbol substitution capability, including nested
> conditoinals, with quite a bit of flexibility. This program also uses
> Text_IO, but the executable is only 81K. It is a 1000 line program
> with 534 non-blank non-comment lines, so it is about 100 times the length
> of hello world in source lines, but certainly not 100 times the length
> in the executable!
> 
> I would guess that you would see the same phenomenon with ObjectAda, i.e.
> that there is a fair amount of fixed overhead, but it does not go up
> with the size of the source file in linear proportion.
> 
>