TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
"W. Wesley Groleau x4923" <[log in to unmask]>
Date:
Mon, 28 Jun 1999 11:09:50 -0400
Reply-To:
Chad Bremmon <[log in to unmask]>
Content-type:
text/plain; charset=us-ascii
Subject:
From:
Chad Bremmon <[log in to unmask]>
X-cc:
Parts/Attachments:
text/plain (63 lines)
The other thing to point out is that the Ada compiler does something.

It doesn't just cram bytes into a binary file.
It checks to see if the bytes are edible first.









"W. Wesley Groleau x4923" <[log in to unmask]> on 06/28/99 09:51:15 AM

Please respond to "W. Wesley Groleau x4923" <[log in to unmask]>








 To:      [log in to unmask]

 cc:      (bcc: Chad Bremmon/OrbMD)



 Subject: Re: [5] Compilation speed data available?









> On a mailing list concerned with another programming language (but not a
> very well-known one*), the following comment appeared today:
>
> > If you want to see a really slow compiler I suggest
> > you try using ADA (yuk!) if you haven't already.
>
> I suspect this may be based on not-very-current experience, and I would
> like to provide some solid evidence that Ada compilers need not be slow.

Starting with nothing compiled, on a project with over 17,000 source files
(million-plus SLOC) ....

On a Sun SPARCserver-1000, with one processor, and source files NFS
mounted, and a fairly heavy load from other users (it's one of our main
fileservers) .....

I ran a script that does gnatmake with optimization for 98 executables.

Took about ten hours.  Takes _MUCH_ less (but I don't have exact numbers) on
a four-processor Ultra-2 with source on local disks.

Apex speed on the same source is slower but comparable.

ATOM RSS1 RSS2