From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_20 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 3 Dec 92 21:39:18 GMT
From: sdd.hp.com!cs.utexas.edu!convex!sercely@hplabs.hpl.hp.com  (Ron Sercely)
Subject: Re: The cost of is separate
Message-ID: <1992Dec03.213918.11878@convex.com>
List-Id: <comp.lang.ada>

Just another view.....

REALLY large packages might also run into compiler limits that subunits would
avoid.  

Also, if you are in a developement (as opposed to maintenance) environment,
and are running high level of optimizations on huge package bodies,
recompilation times might kill you, were subunits would work wonderfully!
(Isn't this why subunits are in the standard?)

Tucker is certainly correct that _some_ optimizations are more difficult to
make when using subunits.

To summarize:

I have always used sub-units during development, then folded the code back
in shortly before production release.

Ron Sercely