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!watserv1!watmath!att!cbnewsl!arny
From: arny@cbnewsl.att.com (arny.b.engelson)
Newsgroups: comp.lang.ada
Subject: Re: Thanks for the Ada Bindings Help.  Next Issue:  Compilers
Keywords: DEC, Compilers, Poor Performance
Message-ID: <1990Sep7.173919.12401@cbnewsl.att.com>
Date: 7 Sep 90 17:39:19 GMT
References: <1725@dinl.mmc.UUCP>
Organization: AT&T Bell Laboratories
List-Id: <comp.lang.ada>

In article <1725@dinl.mmc.UUCP>, schallen@dinl.uucp (Eric Schallenmueller) writes:
> Some of you have been asking about the Ada climate here.  Well, it's in a 
> precarious position due to a rough time we're having with one of our few
> Ada programs.  There appears to be an unacceptable delay due to the compiler.
> The compile delays may be due to poor structuring of Ada code or from a poor
> compiler or both.  Here's the system:
> 
> Development is on a Rational.  For compiles, the system is sent to a DEC box
> (via wire) and the modules are then configured in the proper libraries.
> This takes about eight hours and is done automatically, I think.  
> Then the compile begins under VMS 5.3 and ACS 2.1 (the Ada compiler).
> The compile takes 20 hours for 2100 modules.  In talking to the software lead,
> he said the whole system was thought to be 1/2 Million LOC, but now estimates
> it at 250k LOC.  
> 
> Is this awful response for the compile time or is it typical for an Ada program
> of this size?  How much should structuring of Ada code affect the compile time?
> 
> Eric
> (303) 971-7936

Well, which is it?  500K or 250K?  How do you count lines of code?
Are you including link time in this 20 hours?  Are you doing "ACS COMPILE"
or "Ada"?  And, WHAT SIZE VAX ARE YOU USING?

In any case, this seems slow.  Several things could be causing this.

Got a big enough VAX (and one not being overloaded with other tasks)?
(you want speed, get a bigger CPU)

Got enough main memory?  (a problem if other people are using the system)

Is your working set large enough?  (at least 4000 pages, or suffer death by
page faulting)

Using nested sublibraries? (don't)

Your average module size seems about 100-200 LOC.  If many of them are real
small you pay for compiler startup each time.  If some of them are much
larger and your working set isn't big enough, you get hit with lots of
page faulting.  If you are using lots of generics you get slowed down.

These are just some ideas, I'm sure there are more, and not all of the
above will apply to you.

  -- Arny Engelson   att!wayback!arny

P.S. I know you aren't actually doing the work Eric.  "You" is really
addressed to those doing the build.