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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!princeton!allegra!ulysses!sfmag!sfsup!mdash
From: mdash@sfsup.UUCP
Newsgroups: comp.lang.ada
Subject: Re:  Ada Generic Overhead Inquiry
Message-ID: <1297@sfsup.UUCP>
Date: Thu, 9-Apr-87 06:44:20 EST
Article-I.D.: sfsup.1297
Posted: Thu Apr  9 06:44:20 1987
Date-Received: Sat, 11-Apr-87 12:48:45 EST
References: <8704082021.AA06545@mitre.ARPA>
Reply-To: mdash@/lang2/mdashUUCP (45415-M.D.Scheer)
Distribution: world
Organization: AT&T Information Systems
List-Id: <comp.lang.ada>

Runtime overhead of generics is implementation-dependent.  The
issue is the degree of interpretation done by the code body.
This is determined by the restrictions on instantiations set
by generic formal type parameters, and whether the implementation
chooses to instantiate via code sharing or macro-style expansion.

I believe that most current implementations do limited code sharing
for generic instantiations.  Expect a low runtime TIME overhead for
generics, and a correspondingly high SPACE penalty.