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

[Paolo Carlini <pcarlini at unitus dot it>]

Phil Edwards wrote:

> 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.

Done (90 -> 80)
In fact, as an aside, there is a reason why I was wrapping lines to 90 columns: when I send
libstdc++ diffs they frequently include lines longer that 72 or 80 chars, since the original
sources have lines that long, in the first place!!
Is this a feature or a bug ;-) ?

> 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.

First blush this looks like a very nice idea!

> > 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.

Thanks.
Unfortunately, however, it is not that easy: among other things _MAX_BYTES is currently
declared *private*... grrrrr

P.