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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1bce3f54cf1cba1b X-Google-Attributes: gid103376,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: GNAT Executables: How low can you go? Date: 1996/04/19 Message-ID: <4l82j3$mob@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 148375205 distribution: world references: <4kmq7a$egm@fozzie.sun3.iaf.nl> <4l0o3s$hgt@utrhcs.cs.utwente.nl> <31742475.1CFBAE39@escmail.orl.mmc.com> <317688E9.2781E494@escmail.orl.mmc.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada Date: 1996-04-19T00:00:00+00:00 List-Id: In article <317688E9.2781E494@escmail.orl.mmc.com>, "Theodore E. Dennison" 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