From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Calling inherited primitive operations in Ada Date: Tue, 6 Sep 2022 19:51:44 -0500 Organization: A noiseless patient Spider Message-ID: References: <67b32db0-c4db-466c-ac13-e597e008c762n@googlegroups.com> <401d6f59-2c28-4dd5-9fa6-fccf33b6d645n@googlegroups.com> <12cc33b1-2c39-4057-8a03-623064b06e8en@googlegroups.com> <458444ed-e384-4663-896c-bb38dae3c5cbn@googlegroups.com> Injection-Date: Wed, 7 Sep 2022 00:51:45 -0000 (UTC) Injection-Info: reader01.eternal-september.org; posting-host="1e5353e773e7c4e82af0f578383063bb"; logging-data="57005"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gIjTl0/jgJEniYQAnJ9NX+B06Rfr9RtE=" Cancel-Lock: sha1:0MnMKTBaRpaLK5YJpT8vF9BTgiY= X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-RFC2646: Format=Flowed; Original Xref: reader01.eternal-september.org comp.lang.ada:64294 List-Id: "Emmanuel Briot" wrote in message news:458444ed-e384-4663-896c-bb38dae3c5cbn@googlegroups.com... ... > Randy Brukardt: >> Assuming otherwise is certainly premature optimization. > > I am quoting a bit out of context, though I believe it is close enough. > Designers of containers must care about performance > from the get-go. Otherwise, people might just as well use a list for > everything and just traverse the list all the time. We all > know this would be way too inefficient, of course, which is why there > are various sorts of containers. Anyone who has actually written > performance-sensitive code knows that memory allocations is definitely > something to watch out for, and the library design should definitely take > that into account. Definitely out of context. If you have code which is truly performance sensitive, then it cannot also be portable Ada code. That's because of the wide variety of implementation techniques, especially for generics. (For Janus/Ada, if you have critical performance needs, you have to avoid the use of generics in those critical paths -- sharing overhead is non-zero.) I agree that the design of the containers matters (which is why the we made the sets of operations for the various containers as close as possible, so switching containers is relatively easy). But the indefinite/definite thing is premature optimization - it makes little difference for a Janus/Ada generic, at least in the absence of the full-program optimizer (that we never built). If your code isn't intended to be portable Ada code, then *maybe* it makes sense to worry about such things. But the expectation was always that containers would be useful in cases where the performance is *not* critical - one probably should use a custom data structure for performance critical things. (But most things aren't really performance critical in reality.) Randy.