[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: malloc/libumem
Howard Chu wrote:
Aaron Richton wrote:
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.)
At the moment we're using it as a drop-in, with LD_PRELOAD. In my
first test I modified liblber to call it explicitly, because it didn't
work as an LD_PRELOAD drop-in, but I've managed to coerce umem into
behaving a little better. (It's still likely to crash when preloaded
with arbitrary programs, but it manages to survive its initialization
when preloaded into slapd.)
If you'd like to play with it, I've submitted my patches to the
sourceforge tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=1548294&group_id=162022&atid=822186
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/