Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
Bernd Zeimetz <firstname.lastname@example.org> writes:
>> What's the downsides? I'd guess that if it's GPLed and not in glibc,
>> there's a catch somehow.
glibc is not GPL'd. It's LGPL.
> there're also the google perftools, which are suppsed to work very
> well and we have libgoogle-perftools in Debian.
Hoard is noticably better for OpenLDAP's load profile than Google
perftools (although both of them annihilate the glibc allocator).
>  is very interesting to read in this case. I'd be really interested
> to know why one of those implementations is not the default in glibc,
> and if hoard or perftools provides the better/faster malloc.
>  http://sourceforge.net/projects/goog-perftools/
>  http://bugs.mysql.com/bug.php?id=27063
Well, I don't know if this is a full explanation, but at least Hoard would
have to be relicensed to LGPL to be included in glibc. It's also written
in C++, which I expect would be a problem.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>