[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: