Re: GNAT Executables: How low can you go?

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <317688E9.2781E494@escmail.orl.mmc.com>,
"Theodore E. Dennison" <dennison@escmail.orl.mmc.com> writes: 

|> If we  were talking embedded system, fine. But we're talking OS/2
|> systems here. OS/2 platforms are PCs, which these days come with
|> oodles of hard disk space. In such an environment, executable size
|> just isn't a real concern. I want programs to be robust, not squeezed.

1. That's a very narrow view of the world.  Don't forget about small,
   portable PDA-like or tablet-based devices, with much more constrained
   hard disk space.

2. What does robustness have to do with it?  We're not talking about
   programmers cutting corners to save space, but about a compiler doing
   its job well.

3. You describe a typical end-user environment, in which executables
   consume 3% of your disk space.  However, in a development environment,
   there are projects that fill up disks with executables, requiring the
   expenditure of more money to buy more disks.  (Indeed, as I write
   this, my OS/2 machine is busy doing a low-level format of the new
   2.25GB disk I installed yesterday, for just this reason.) If you are
   planning a large project with thousands of files, a compiler producing
   executables ten times as large as necessary costs real money.

There are other considerations in favor of compact code as well.  To the
extent that the size of the executable reflects the size of the object
code itself, more compact code means faster loading and fewer I-cache
misses, resulting in faster execution.  For an Ada-to-Java-bytecode
compiler, more compact code means faster transmission of an applet over
the web.

|> So what you are saying is this is a marketing issue?
|>
|> Again, I don't believe you here. I don't bat an eylash at any
|> executable less than one MEG. If someone raises nonsense such as
|> executable size as argument against Ada, you're just wasting your
|> time trying to placate them. They will just keep shifting their
|> argument, becuase the real problem isn't executable size, its that
|> its not C. Don't even bother.

This is nonsense.  Someone who comes to the table without any prejudices
about Ada is sure to walk away with a negative impression if he sees
executables an order of magnitude larger than those produced using C.

--
Norman H. Cohen    ncohen@watson.ibm.com