This is the mail archive of the
mailing list for the libstdc++ project.
Re: Less good ;-) results from Rittle's string allocator
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
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 - firstname.lastname@example.org - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | An AOL Company