Re: malloc/libumem

[Aaron Richton <richton@nbcs.rutgers.edu>]

> DB. Really fixing that requires a smarter malloc.

You've mentioned libumem as that "smarter malloc" along with portability 
concerns: are you using libumem as a drop-in, or are you seeing 
performance improvements based off umem_alloc(3MALLOC) use?

If it's a drop-in, I can't see anything bad about an autoconf check as 
Quanah suggested. Take performance if you can get it, take portability 
when you can't. Portable performance should help both cases. At the cost 
of seconds of compile-time decision making, I can't see the flip side of 
the coin. (Indeed, if this is the case, I have half a mind to LD_PRELOAD 
in my slapd init scripts today.)

If it's umem_alloc, I don't see that much bad, although it certainly could 
introduce new issues...but it'd probably be worth it in the long run, as 
(a) libumem becomes increasingly portable, assuming an active community 
there and/or (b) OpenLDAP's use of umem_alloc and friends gets field 
tested by the OpenLDAP community.