Allocator tuning parameters

[Matt Austern]

On Jan 26, 2004, at 1:33 AM, Dhruv Matani wrote:

> On Sat, 2004-01-24 at 01:48, Loren James Rittle wrote:
> [...]
>
>> There is also the issue that the default pool allocator has some cases
>> where its performance profile truly stinks (for single-threaded, we
>> think it beats most per-platform malloc implementations; however I
>> have test cases where that is not always true).  Since we never
>> figured out the best way to set the default allocator on a
>> per-platform basis, the compromise was to always allow one to disable
>> the pool cache.
>
> I have a suggestion that may not be always feasable, because it 
> involves
> the client to instantiate an allocator explicitly.
>
> Firstly, to make this work, we need to make each allocator truly type
> parameterized, meaning that some_allocator<int> and
> some_allocator<float> will not be sharing pools. As I have mentioned
> earlier, this would improve the efficiency too.

It would improve some kinds of efficiency for some usage cases, at
the cost of making memory fragmentation worse.

The original HP STL used a single pool per container.  We changed
it to use one pool per allocator instead, and this was generally 
believed
to be a huge improvement.

			--Matt