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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,45abc3b718b20aa3 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Two ideas for the next Ada standard Date: 1996/09/06 Message-ID: #1/1 X-Deja-AN: 178872835 references: <5009h5$ir4@netline-fddi.jpl.nasa.gov> <503sbo$j45@goanna.cs.rmit.edu.au> <507akg$t9u@krusty.irvine.com> <322D0803.3E5E@iag.net> <322F94E9.28C6@iag.net> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-09-06T00:00:00+00:00 List-Id: T.E.D. says "True, but only on the body of the inlined or generic subprogram. The proposed change would make compilation units dependant on every spec and body "with"ed in every spec AND BODY (recursively). In my experience, package bodies tend to have a LOT more "with"'s than specs. Compilations that now take hours might end up taking DAYS! Then again, I guess there is a limiting factor (ie: the total # of specs and bodies in the system). This would just drasticly increase the % of compilation units in the entire project that the average compilation unit depends on." That's very confused. Putting the text of the private part in the same file as the body creates a source dependence it is true, meaning that if you modify a body, you have to recompile clients, but it does not mean that a client has to compile the body (that is only needed in the presence of inlining or generics), so the presence of with's in the body is quite irrelevant. So the effect is indeed to increase amount of compilation, but there is no significant increase in the compilation time of any one unit (a very small effect from opening more files, that's all). As for compilations taking DAYS (with a shout), this is like political campaign rhetoric, it results in FUD but is short on technical facts :-) Early on people used to assume that the source based approach would mean that GNAT was much slower than xxx compiler, but you can never make facile assumptions like this without actually measuring things. GNAT compiles things pretty fast, especially when it comes to client specs, which only go through part of the compilation process (no code is generated for such specs of course). For example, when I compile the DEC Starlet package on my 133MHz Pentium note book, it takes just over a minute to compile a client that with's this package. Starlet is 62,000 lines of code with 45,000 lines non-comment non-blank. Furthermore, that time is with the slow debugging checks on version of the compiler (this is still the only version of the compiler that we distribute, although we are coming close to the point of distributing the fast version). To find a GNAT compilation that took days, you would either have to have an abysmally slow machine (perhaps a 386 with 4K bytes of memory), or you would need hundreds of millions of lines of Ada code!