Re: Less good ;-) results from Rittle's string allocator

[Phil Edwards <pedwards at disaster dot jaj dot com>]

As an aside, Paolo, your mailreader program is wrapping lines at something
like 95 columns.  If convenient, please consider wrapping at around 75 or 80.

On Tue, Nov 27, 2001 at 02:33:33PM +0100, Paolo Carlini wrote:
> In the next few days I'd like to test a little bit the effect of Phil Edwards proposal to
> increase _MAX_BYTES to 256 in stl_alloc.h (the new one would be modified s/256/512/).

I'm a bit nervous there.  How often do we plan on requesting chunks of
half a kilobyte?

More specifically, how often will memory clients /other than basic_string/
be requesting chunks of a half-K at a time?

I wanted to raise it past 128 because I've been seeing a fair number
of programs lately using containers of Foo where sizeof(Foo) > 128, and
they weren't benefitting from the memory pool.  If we raise _MAX_BYTES to
something large, I'm worried that basic_string would be the only client,
and that we're making non-string-using programs pay for it.


Let me throw out an idea I had while typing the last paragraph:  we could
make the _MAX_BYTES a template parameter of the allocator:

 old:      __default_alloc_template<true,0>
 new:      __default_alloc_template<true,0, _MAX_BYTES=256>

or something similar.  Then basic_string can have its own memory pool.


> As regards this last point, what do you all believe of including stl_alloc.h in
> basic_string.tcc?

It already is, via std_memory.h.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams