Date: Mon, 14 Feb 2005 20:49:39 +1000 From: Andrew MacIntyre <andymac@bullseye.apana.org.au> To: David Schultz <das@freebsd.org> Cc: Jason Henson <jason@ec.rr.com> Subject: Re: malloc vs ptmalloc2 Message-ID: <42108243.9030800@bullseye.apana.org.au> In-Reply-To: <20050213082128.GA68307@VARK.MIT.EDU> References: <1108277558l.86500l.0l@BARTON> <20050213082128.GA68307@VARK.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote:
> Other than that, I don't know enough
> details about ptmalloc to speculate, except to say that for most
> real-world workloads on modern systems, the impact of the malloc
> implementation is likely to be negligible. Of course, test
> results would be interesting...
Some language interpreters by design malloc()/realloc()/free() memory
constantly. Python being a well known example of such an interpreter.
Because the issues with memory allocators are legion in the context of a
multitude of platforms, Python eventually gained a highly specialised
allocator geared to its usage patterns (which brought some other
benefits with it too). I think I've seen references to Perl doing
something similar.
The performance degradations due to corner cases in allocator design
exposed by Python (when using native platform allocators rather than its
own) is often painful.
Nothing comes for free though, and Python's allocator has a limitation
that a small percentage of users find painfull - it doesn't return
vacant arenas to the OS, which with some usage patterns gives rise to
large amounts of wasted swap space.
-------------------------------------------------------------------------
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370
andymac@pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42108243.9030800>