apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: SMS usage patterns, hierarchies
Date Wed, 11 Jul 2001 16:08:47 GMT
> 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)

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.

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()).


View raw message