Re: Executable File Size Differences

[Stanley Allen <sallen@ghgcorp.com>]

Georgi Savov:

> 
> Robert P. Kuzmicki:
> >
> > I tried compiling a simple "Hello World" program with the Thomson
> > Software's ActivAda for Windows and Thomson's new "ObjectAda". The
> > ActivAda version produces a executable file size 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 sizes.
> >
> > Can anyone enlighten me here?
>
> Probably you are looking at the Debug version of the EXE file.
> Try making a Release Version. I did. It is 83K.
> 
> Georgi Savov

But this is still unacceptable isn't it?  Why should "Hello, world"
take 83K of executable code?  Maybe Microsoft C++ is using a DLL
for the I/O and ObjectAda is including it in the EXE.  But I'll bet
ObjectAda *is* using DLL's too, and that there's another reason.

I'm glad someone brought this topic up, because I've been
waiting for a chance to get on a soapbox.


I am not convinced that current Ada compilers could be used to

produce code for "major" PC software that would have acceptable

memory performance.  I'm thinking of full-featured products,

products that compete in the cut-throat PC software market at

the top echelons, where "feature-itis" issues are critical to
commercial success.  Products like WordPerfect, Netscape
Navigator, and Microsoft Access.  Could Ada be used to develop
commercially successful products in this arena?  I don't think
so.



I think the executable speed of the code produced by current

Ada compilers is up to snuff.  And I believe that, in general,

the number of bytes of executable code produced by current

Ada compilers for this or that section of source code is

competitive with that produced by C/C++ compilers for

functionally equivalent code segments.  But I *don't* believe

that the size of the executables produced by the linkers, and the

amount of RAM necessary to run these executables, is currently

acceptable for producing products in the above-described arena.



The problem is an old one: the lack of "smart linkers" which

would include only the necessary code from an Ada package, and

avoid linking in the unused bulk that never gets invoked.



This is an old complaint but still a valid one.  I've been in

the Ada bidness for about 10 years now, and the only smart

linker I can recall for PCs (my exposure may be weak here) was

Meridian.  Vendors seem to be content with the Ada-binder/

system-loader approach (a special Ada-specific binding step 

is performed to gather all the object files, which are then

passed to a general system-supplied loader, like Microsoft's
linker).  This approach has the advantage of portability and
easy implementation.  But since most Ada implementations
produce one object file for each package, a reference to
a procedure or variable in that package causes the low-level
linker to include the entire object module into the executable,
whether most of it is used or not.  



Not many Ada projects have historically demanded smart linkers
(except perhaps in the embedded controller domain), maybe
becuase not many DoD project managers have squawked about

code size.  The issue has never been "hot" among Ada developers

like other issues, for example speed of code execution, or

tasking/RTL performance.  Memory has generally been cheap

enough to justify upgrading the "project development" machine

and the limited number (sometimes only one) of "target" machines.



But in a large office complex with 100+ PC, careful thinking

must be given to purchasing a new WWW browser that would

require bumping everyone's RAM up by 8Mb or more.  And IMHO,

this is the kind of thing that would happen if current Ada
compilers were used as the development tool for producing
that new browser.



Smart linking is an simple idea which is hard to implement.

But it can be done, and I think it needs to be done as one

of the steps to make Ada a viable option for commercial

software developers, in addition to the work underway to

make Ada work with things like the Windows API.

There is no technical barrier, but it may be just a matter
of market dynamics: the C/C++ compiler vendors for the PC,
particularly Microsoft, Borland, and Symantec, have survived
in an aggressive business environment where their products
are scrutinized in trade journals and mass-market magazines
every few months.  Comparisons between them for code size,
execution speed, ease of use, feature sets, etc., are all
scored by developers and editors who put each product 
through a suite of tests and evaluate the results for the PC
programming community.  Detailed discussion of the merits
and demerits of each system (and subsystem) are provided to
give the readers an understanding of the trade-offs involved.
"Editor's choice" awards are given to the best, and numeric
results for the winners and losers are posted in large type
at the beginning of the article.

I assure you that these results are carefully considered 
as compiler selection criteria by developers and project
managers.


Of course, Ada has not hit the "big time" yet (cross your
fingers), but comparisons can be done on a smaller scale
within the Ada community: there is a standard compiler
evaluation suite (ACES:

    http://sw-eng.falls-church.va.us/AdaIC/testing/aces/README.html

) and I'm always suprised that there is so little published
about the results of such tests.  


Perhaps if such results were published, Ada vendors would be
provoked to go beyond the current state-of-the-art for Ada
compilers & up to the state-of-the-art for C/C++ compilers.


Stanley Allen
sallen@ghgcorp.com