Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator
Oleg Verych <olecom@flower.upol.cz> writes:
> Message-ID: <46128051.9000609@redhat.com>
> WWW: <http://thread.gmane.org/gmane.linux.kernel/511629>
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.
See:
http://www.openldap.org/lists/openldap-devel/200608/msg00039.html
http://www.openldap.org/lists/openldap-devel/200611/msg00004.html
http://highlandsun.com/hyc/malloc/
You can also see on those graphs, particularly the last page, the relative
performance of tcmalloc, which is more efficient but a little slower.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
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>