So, we should crib a memory pool API from someplace (IIRC, Timo
Sirainen
has a good one in Dovecot that is MIT licensed) or write our own in
Glib
style and send it upstream (probably a bigger project than it needs to
be).
Why? To avoid the constant free(3)'ing?
Memory pools are big chunks of malloc() memory that we request from the
system and then use for ourselves as needed in smaller pieces. In
Apache's
APR implementation (which is really, really bloated) you can also nest
pools. Rather than a malloc/free pair for every string, you just make a
pool, "malloc" from the pool recklessly ;-) and then when you're all
done,
free the entire pool back to the system.
I'm in favor of stability, then optimizing later. :) In all
seriousness, this is what FreeBSD's malloc(3) call does (and is why
it's really quick).
http://www.freebsd.org/cgi/man.cgi?query=malloc&sektion=3
If the allocation of a pool/cache isn't big enough for the tastes of
the application authors, they can increase it by factors of two. See
the '>' malloc(3) flag. Cool, huh?
-sc
--
Sean Chittenden
