Re: Calling inherited primitive operations in Ada

["Randy Brukardt" <randy@rrsoftware.com>]

"Emmanuel Briot" <briot.emmanuel@gmail.com> 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.