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

[Brad Spencer <spencer at infointeractive dot com>]

I've been lurking for a while and have been very interested in the
memory allocation discussions going on here.  This is the main area
that has kept our group from upgrading to gcc-3.x.  I have a couple of
quick comments about this (see below).
	
On Tue, Nov 27, 2001 at 02:04:55PM -0500, Phil Edwards wrote:
> 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 have a related question:  How often would an application like to use
the memory pool implementation provided by the library's allocators to
manage dynamic blocks of abitrary (i.e. > 128 byte) size?  I do! :)
 
> 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.

This would be excellent for my purposes (I write a lot of libraries
for others as well as a lot of applications) because I could take some
code that requires dynamic allocation of realtively large chunks and
instantiate my own allocator.  Of course, it would be non-standard,
but that's inevitable (isn't it?).  Right now, in one case, I use the 2.95.3
std::allocator to manage blocks from size 128 bytes up to 64K.
Luckily, they're _usually_ only 128 bytes long, so the memory pool
usage pays off, but it'd be fantastic if I could use the _very_ nice
pool system with my own maximum size.

It might also be reasonable to let me specialize the _ALIGN
(well, really the _NFREELISTS) under such circumstances.  I might not
need 8-byte granularity.  For the example above, it would be a waste.

-- 
-----------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
  Systems Architect | InfoInterActive Corp. | An AOL Company