Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
Bernd Zeimetz <bernd@bzed.de> 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[1], 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).
> [2] 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.
> [1] http://sourceforge.net/projects/goog-perftools/
> [2] 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: