apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <d...@arctic.org>
Subject Re: Observations on fragmentation in SMS pools
Date Sun, 08 Jul 2001 18:11:08 GMT
On Sun, 8 Jul 2001, Jon Travis wrote:

> I talked to rbb about this not too long ago, and he told me that you
> did a lot of performance work, and that is why pools use their own
> allocation scheme (8k blocks, freelists, etc.) instead of using a
> total malloc() oriented scheme.

yes and no.  i can't say that i ever compared an implemention of apache
using malloc/free to one just using palloc ... it would have been insane
to try to go about adding free() calls everywhere they would have been
required to do that.  (and you can sit back and do some math and figure
out that it would be slower by virtue of having to track many more
pointers, and double the function call overhead of each allocation.)

so given the restriction that i was implementing palloc -- an allocator
with only a "group free" operation of all allocated elements, then what i
did was to tune the apache-1.3 (maybe it was 1.2 at the time) code.  the
palloc stuff goes back to before apache 1.0, and i'm pretty sure it's
rst's code (but you should ask the real old timers, not me, i came on
board around 1.2).  there were definitely a few bugs in both the alloc.c
code, and in the way apache used it.  i don't remember the details (but
i'm responsible for the mess o' ifdefs of debugging code).

another thing you need to consider is that this was a
process-per-connection server -- and the global free list made a lot of
sense.  but i don't remember actually timing it against using malloc/free
directly for the blocks.  i think that would have sucked on many of the
unixes at the time -- some of which it was standard practice to use
gnumalloc instead of libc malloc to get a perf improvement.  it's
important to remember that malloc/free haven't stood still, and the
technology in there has improved.

> You are right that libc malloc()
> implementations are very fast, can deal with threading issues
> more elegantly than we could in APR, and have other niceties
> (different sized buckets, etc.).  There is currently a ton of locking
> in the pool implementation to deal with the threads (and we are
> actually missing a lock in one needed location, I believe).

you know, i'd be tempted to say get rid of the free list even in the
process-per-connection servers.  it simplifies the code, which is way
better for maintenance.  and it's probably a toss up today as to which is
faster.  (it might be slower on ancient unixes, but, um, i fail to see the
problem ;)


View raw message