Re: Thanks for the Ada Bindings Help. Next Issue: Compilers

[eachus@linus.mitre.org (Robert I. Eachus)]

     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...