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.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!agate!linus!linus!eachus From: eachus@linus.mitre.org (Robert I. Eachus) Newsgroups: comp.lang.ada Subject: Re: Thanks for the Ada Bindings Help. Next Issue: Compilers Message-ID: Date: 7 Sep 90 19:58:50 GMT References: <1725@dinl.mmc.UUCP> Sender: usenet@linus.mitre.org Organization: The Mitre Corporation, Bedford, MA In-reply-to: schallen@dinl.uucp's message of 6 Sep 90 20:57:10 GMT List-Id: Quick arithmetic gives 250k SLOC / 20 hours ~ 200 lines/minute. Not great, even for Ada compilers, but I'd want a lot more information before I called it bad... What model VAX are you compiling on? (If less than 2 MIPS, stop here and upgrade.) What sort of disks are you using, and how full and/or how fragmented are they? On fast machines, Ada compiler performance is usually dominated by disk performance. Faster disks mean faster compiles. If it takes 8 hours to transfer the source, the bottleneck on that path is at about 250K * 40 char * 8 bits/8 * 3600 = 3000 baud. About the expected throughput for a 9600 BPS line. If the compiler is sending listings back by the same path, the time to send the listings may be dominating the process. Get a faster connection. (Ethernet?) One last question, why are you recompiling the world on a regular basis? There are times when a design change in an Ada program forces such a compile, you may need to recompile the world when installing a compiler upgrade, and there are times when configuration management policies will require such a compile. But on most Ada programs I have been associated with, world compiles are scheduled for nights or weekends when they don't disrupt development. If you are recompiling everything more often than once every two or three months, there is something wrong with your configuration management system. Tools which are fine for small projects don't work well on large projects. Now that we have disposed of the non-Ada possibilities there are a few Ada features which can cause slow recompiles if they are misused. (Or if they are used correctly which is an entirely different case... If a project estimated at several hundred thousand lines of code can be written in 15K lines of Ada by nesting generics 4 or 5 deep, do you care that the compile takes 4 hours?) There are four main ways to choke an Ada compiler: with clauses, use clauses, subunits, and generics. If an Ada program is written as lots of small compilation units (good), but due to poor design or programmer laziness each unit has dozens of with clauses, then the compiler can spend more time loading context information than compiling the program. And since importing context is a file intensive process, slow disks will really kill you. If a program has lots of use clauses for packages with integer types, the compiler can spend lots of time deciding which plus operator the programmer wanted. The compiler will either get it right or complain, but the time to got through 100 visible definitions of "+", or GET can cause a major slowdown. There exist tools to fully qualify all references, and they make maintenance much easier anyway. (Except that most don't have a way of determining which use clauses should be kept. It is a judgement call, but most programmers err on the side of too many use clauses. You really have to be creative to choke an Ada compiler with subunits, but it can be done. Most compilers have to do some processing of all the parent units of a subunit when the subunit is compiled. If the parent is, say a 50 line package body with twelve 300 line subunits, no big deal. But we saw on project where the subunits were nested 10 or 12 levels deep, with large numbers of declarations at each level, but the leaf nodes were 30 lines long. Last but not least generics. Generics are a very useful tool when used right, but often processing unnecessary generic instantiations will eat lots of compiler time (and some run time too!) For example, I remember one package body where almost every subprogram contained an instance of TEXT_IO.INTEGER_IO for STANDARD.INTEGER. Replacing that with one instance in the package body tripled the compilation speed. (Some compilers have a special check for this particular case to speed up ACVC compiles.) I hope that these suggestions help. I am posting this so that other people can try to avoid these traps. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...