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

[Adam Borowski <kilobyte@angband.pl>]

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote:
> 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.

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.