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 ;) -dean
