Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

[Russ Allbery <rra@debian.org>]

Steinar H Gunderson <sgunderson@bigfoot.com> writes:
> On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote:

>> The problem with this theory (basically, that glibc is taking a
>> performance penalty by giving memory back to the system and hence being
>> more space efficient) is that not only is Hoard significantly faster
>> than glibc for OpenLDAP, it's also more space-efficient and allocates
>> less total memory as soon as there are multiple clients querying the
>> server at the same time.

> I guess it depends on your access patterns. In any case, I do not oppose
> this ITP, but I think it should be noted that it doesn't give memory
> back to the operating system if that is indeed the case.

Studying the Hoard paper, it appears that it does release memory back to
the operating system if the allocated block is "large."  The general
description is very similar to the description of what glibc does,
although I don't know if there's a difference in practice in how much
memory is released and I don't know if it uses exactly the same technique
on Linux.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>