apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: SMS usage patterns, hierarchies
Date Thu, 12 Jul 2001 09:07:43 GMT
On Wed, Jul 11, 2001 at 09:08:47AM -0700, Aaron Bannert wrote:
> > also, would someone like to write an apr_sms_trivial_using_hashchains?
> > 
> > the idea here would be that the size of the memory block
> > is used as a hash-lookup into the currently-available free chain,
> > instead of list-walking.
> > 
> > surely, that saves time, yes?
> > 
> > anyone care to refute this hypothesis and proposal?
> I'm pretty sure that's a bad idea. The whole point of pools was to take
> advantage of the finite lifetime of a request and it's memory requirements.
> Instead of having to balance all the malloc()s with free()s (where lots
> of differently sized and fairly small free()s followed by a number of
> malloc()s, over and over, can be very inefficient), pools simply dump
> all the memory allocated since some finite time (ie pool creation).
> That way we get essentially one bulk free() to replace a bunch of expensive
> mini-free()s. (At least that's the way I see pools being optimal inside httpd)
ah ha.

> Ignoring the fact that a linear search through lists of ~20 (in this case)
> is probably going to be faster than a hash table, this case would only
> be useful if we are trying to optimize best-fit, and would only really
> work if the blocks we've already free()d are almost always *exactly*
> the same size as the ones we want to alloc(). Even if the block you
> are requesting is only slightly different, the hash would fail and we'd have
> to call the parent or do something else funky.

ah ha!

okay, now i start to get it.  an explanation of the requirements
specification, which is the first stage to understanding why this
is needed.

thank you very much, aaron.

> So, I'd rather see us do a next-fit implementation (a linked list of
> bins, search down until you find one that fits) at the thread level,
> and then create child-sms for each request that act like pools (and
> don't implement free()).

ah ha!

... is that different from apr_sms_trivial, as it stands, then?

by the way: another mallocator that fits the requirements is talloc.c
this trivial allocator *never* frees, and it also doesn't *reuse*

is that a viable option?

when you reset, you destroy the entire list [i.e. you never
consider reuse]

you only allocate large blocks and give out bits of them.
use a list, because aaron and sander and equally more clued-up
minds reckon these are reasonably efficient.

you provide no realloc.

you provide no free.

only [sms_] alloc, reset and destroy.



View raw message