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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3cd797aa3bdcb07b X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: performance of Generic and strings Date: 1999/08/11 Message-ID: <37B1B634.543D131D@pwfl.com>#1/1 X-Deja-AN: 511521337 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <37B18AB6.BBAEF44A@pwfl.com> <7osak8$gph$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: e108678@pwflcom Newsgroups: comp.lang.ada Date: 1999-08-11T00:00:00+00:00 List-Id: Robert Dewar wrote: > There is no such overhead in typical implementations of > generics, so it is not clear what you are talking about. > My understanding was that there are two ways to implement generics - one was macro-like expansion and the other was via some sort of "profile" information which could make the code common, but change the behavior for each generic instance. (For example, keeping pointers to subprograms, size information for various data types, etc. and the generated code operates using the profile info when calling subprograms, moving data, etc.) Clearly, a code expansion technique would pose no time penalty - provided the compiler did not do some different form of code generation when it went to compile generics vs standard stuff. (I believe we've had examples of this in earlier Ada compilers.) There is, however, an obvious space penalty as well as a serious verification issue to this technique. Given that Thomas was originally complaining of a speed penalty, I suppose I was presuming his compiler must be using an implementation technique that would account for this. I have also been informed by other experts in the Ada compilation field that there are certain language issues involved with the macro expansion technique which make the profile technique more attractive. (I won't name names, not wishing to draw anyone unwillingly into the fray, but feel free to leap to my defense here. :-) As to which is more commonly used? Not being a compiler vendor myself, I'll defer to those who make it their business to know the market. However, between the two, I think I'd rather have instantiation done with some sort of profile information rather than expansion. While normally, I'd come down on the side of speed, in this instance, I'd prefer the space savings as long as the time penalty was minimal. It also greatly reduces verification problems, which is a tremendous concern around here. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/