stt@inmet.inmet.com (09/14/90)
Re: Compilation speed, generics, etc. There is nothing wrong with using generics "heavily" so long as you realize that in most cases, they will be treated roughly like an "include" or a macro expansion upon instantiation. Therefore, in calculating the number of lines compiled, you should multiply the number of instantiations of any generic by the number of lines of code in the generic spec and body. As far as recompiling the world, your problem seems to be that the "specs" to your "core" are not sufficiently stable, or that your "core" includes generic bodies mixed in with non-generic code. It is important to remember that, for most compilers, instantiating a generic is analagous to "inlining" a subprogram call. Both create a dependence from the point of instantiation/call on the *body* of the defining unit. Generic instantiations can be particularly troublesome since they are often themselves in a spec, and therefore anything which depends on this spec, indirectly depends on the *body* of the generic. There are various remedies. Eventually, it is hoped that most compilers will break this dependence on generic bodies, by compiling the bodies of instantiations as implicitly separate compilation (sub)units. However, until that is widespread, you would do well to keep your generic bodies stable, or only instantiate them in other bodies. If you have an instantiation in a "core" spec, you can instead put a regular package spec there, and then implement that package spec using an instantiation with a simple layering (i.e., trivial subprogram bodies which just "pass the buck" to the subprograms provided by a generic instantiation). Similarly, avoid the use of pragma-Inline until the system is debugged and stable. Pragma Inline generally slows down compiles, saves only a modest amount of run-time (in the "big" picture), and creates recompilation nightmares. Finally, once you have worked around the dangers of generics and inlines, KEEP YOUR SPECS STABLE. This may mean providing extra "reserved" interfaces, escape hatches, etc., to handle last-minute changes without having to recompile "core" specs. Once things are relatively debugged and stable, you should eliminate the work-arounds. Therefore, all work-arounds should be visibly marked in the source. Although the Rational is a great environment, it definitely lulls people into forgetting about the requirements of Ada compilers for "real" targets, where due to optimization requirements, it is necessary to expand generics inline, and it is not generally practical to maintain enough of a program library database to support incremental recompilation. I hope this helps... S. Tucker Taft stt@inmet.inmet.com; uunet!inmet!stt Intermetrics, Inc. 733 Concord Avenue Cambridge, MA 02138