Re: Performance problem in aset.c

* Tom Lane <tgl@sss.pgh.pa.us> [000711 22:23] wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > Can you maintain one free list for each power of 2 (which it might already
> > be doing by the look of it), and always allocate the max size for the list.
> > Then when you want a 10k chunk, you get a 16k chunk, but you know from the
> > request size which list to go to, and anything on the list will satisfy the
> > requirement.
> 
> That is how it works for small chunks (< 1K with the current
> parameters).  I don't think we want to do it that way for really
> huge chunks though.
> 
> Maybe the right answer is to eliminate the gap between small chunks
> (which basically work as Philip sketches above) and huge chunks (for
> which we fall back on malloc).  The problem is with the stuff in
> between, for which we have a kind of half-baked approach...

Er, are you guys seriously layering your own general purpose allocator
over the OS/c library allocator?

Don't do that!

The only time you may want to do this is if you're doing a special purpose
allocator like a zone or slab allocator, otherwise it's a pessimization.
The algorithms you're discussing to fix these leaks have been implemented
in almost any modern allocator that I know of.

Sorry if i'm totally off base, but "for which we fall back on malloc"
makes me wonder what's going on here.

thanks,
-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."