|
Home > Archive > Debian Developers > June 2007 > Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and effi
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and effi
|
|
| Adam Borowski 2007-06-26, 1:21 pm |
| On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote:
> Oleg Verych <olecom@flower.upol.cz> writes:
> 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.
Too bad, it performs insanely bad in even such a common case as linear
allocation. I would say that a good percentage of software builds their
main (ie, most memory-heavy) data structure once. Like, apt loads the
dependency tree, doing hardly any mallocs later, and so on.
Such a pattern can be easily approximated by just for(){malloc;dirty},
and I ran a series of such benchmarks.
10 concurrent threads, 2-way machine. # of allocs is constant but varies
between tests.
random(20)+1 bytes
malloc 29.651s
g_slice 21.544s
hoard 2m33.183s
8 bytes
malloc 17.693s
g_slice 10.690s
hoard 2m22.019s
80 bytes
malloc 4.548s
g_slice 2.823s
hoard 16.372s
random(256)+1 bytes
malloc 4.733s
g_slice 5.150s
hoard 17.253s
64KB
malloc 0.474s
g_slice 0.454s
hoard 4.516s
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|