Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
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.
/* Steinar */
--
Homepage: http://www.sesse.net/
Reply to:
- References:
- Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Russ Allbery <rra@debian.org>
- Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
- Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Bernd Zeimetz <bernd@bzed.de>
- Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Russ Allbery <rra@debian.org>
- (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Oleg Verych <olecom@flower.upol.cz>
- Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
- From: Russ Allbery <rra@debian.org>