Re: separate keyword and separate compilation with GNAT?

[dewar@cs.nyu.edu (Robert Dewar)]

Wes said

"Someone complained about the incredible length of time it would take to
compile a "large" system with GNAT due to GNAT's method of also compiling
subunits.  A similar complaint could be made about the need to "re-compile"
EVERYTHING higher on the dependency tree."

Let's not confuse two things here. The issue of requiring a complete
subtree to be present for compiling is quite a different issue from
"recompiling" withed units from source.

Yes, I have heard people complain that this must be "incredibly 
inefficient" or somesuch, but in fact I am not at all sure it is
even slightly inefficient. The trouble with the library approach is
that:

  first: you have to write the library when you compile, a step that
	we avoid completely.

  second: you have to read in all the data from the library. Often the
	library data is much bigger than sources, and just the I/O
	can be significant.

  third: you have to process/relocate etc. the data, which can be
	time consuming.

It is not at *all* obvious that recompiling from source is slower.

As I have noted before, the only versions of GNAT that anyone uses are
debugging versions which are dramatically slowed down by huge amounts
of debugging junk (we can be talking about a factor of several in
speed here). Still GNAT seems quite reasonably fast, and indeed it
is still typically the case that more time is spent in the backend
than the frontend, especially if optimization is turned on. Code
is not compiled for withed units, so any alledged slow down from
recompiling withed units can only affect the frontend time anyway.

As Wes notes, there are many other advantages of the source based
approach -- and indeed improved compilation performance may be
one of them :-)