This is the mail archive of the
mailing list for the libstdc++ project.
Re: Less good ;-) results from Rittle's string allocator
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 27 Nov 2001 21:00:52 +0100
- Subject: Re: Less good ;-) results from Rittle's string allocator
- References: <3C03962D.A893E65D@unitus.it> <20011127140455.A12673@disaster.jaj.com>
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.
Unfortunately, however, it is not that easy: among other things _MAX_BYTES is currently
declared *private*... grrrrr