Re: Ada containers and custom allocators

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 11 Sty, 23:41, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>
>> Why does it give spectacular performance improvements?
>> Doesn't this indicate that the default storage management
>> is needlessly inefficient?
>
> Default storage management is always needlessly inefficient, because
> it is general and cannot benefit from any additional knowledge about
> what will be allocated. Every single bit of additional knowledge is an
> improvement opportunity in some area. Fixed-size allocators can use
> faster algorithms than general allocators.

True, but the container implementation knows whether it is allocating
fixed-size objects.

> Another axis of improvement with custom allocators is thread-safety.

Good point.  I'd like to have a language where the compiler can tell
which objects are shared by more than one thread.  But that's not Ada
(nor is it C++).

> The global allocator cannot assume anything about threading and has to
> be defensive in relation to threads, which means that it has to
> proactively synchronize everything, always - just in case.

You don't necessarily have to lock every allocation and deallocation.
There are more efficient schemes, but you're right -- there is a
cost.

- Bob