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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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: Stanley Allen Subject: Re: Executable File Size Differences Date: 1996/09/28 Message-ID: <324D6631.4F3F@ghgcorp.com> X-Deja-AN: 185878666 references: <52bmn5$7r0@sjx-ixn6.ix.netcom.com> <52bq9m$7gn@nr1.ottawa.istar.net> content-type: text/plain; charset=us-ascii organization: GHG Internet Services mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-09-28T00:00:00+00:00 List-Id: 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