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

[Brad Spencer <spencer at infointeractive dot com>]

On Thu, Nov 29, 2001 at 04:20:08PM -0500, Phil Edwards wrote:
> > 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?).
> 
> Depending on any particular allocation strategy is non-standard, yes.
> I do feel we need to give the users more control over what strategy is used.

Right.  I guess what I'm saying is that in most cases as stay strictly
standard as much as possible, but I'd like to have a nice memory pool
allocator.  The library has one that I'm willing to use as an
extension.  My alternative is to write/find another one, which also
wouldn't be standard, so I'm no worse off.
 
> Even if the off-the-cuff idea above were implemented -- and it /is/ ugly
> as sin :-) -- we couldn't recommend that users make use of names in the
> implementation namespace.  They'd have to be wrapped and exposed somehow.

Perhaps in ext?

> > 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.
> 
> We have to be careful not to violate the requirement that the memory
> returned by a standard-conforming allocator is properly aligned for any type.
> Other than that, yeah, I could see this too.

Sorry, I confused things with poor wording, there.  What I meant to
say was that I don't really care about alignment (8-byte is fine), but
what I might want to tweak is the number of freelists (which is
computed from the _ALIGN and _MAX_BYTES).  For example, I might want
to set _MAX_BYTES to 1024, but that would give 1024 / 8 = 128 separate
free lists, which, as far as I can tell, represent pools of size 8,
16, 24, 32, ..., 1024.  If I was using a custom allocator, I might
know that I would only want, say, sizes of 128, 256, 384, ..., 1024,
so I'd only need 8 free lists.  The rest would never be touched.

In summary, what I'm asking is that since the memory pool logic in the
library is nice, well-optimized, well-maintained, and bug-free (?),
it'd be nice to expose it as an extension since I'd have to go make
one or find one anyway.  I would be forever greatful :)

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