From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 14 12:10:12 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22E6D16A4CE for ; Mon, 14 Feb 2005 12:10:12 +0000 (GMT) Received: from mail.acis.com.au (atlantis.acis.com.au [203.14.230.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 67A1743D1D for ; Mon, 14 Feb 2005 12:10:10 +0000 (GMT) (envelope-from andymac@bullseye.apana.org.au) Received: (qmail 61202 invoked from network); 14 Feb 2005 12:10:05 -0000 Received: from unknown (HELO bullseye.apana.org.au) (210.8.160.11) by atlantis.acis.com.au with SMTP; 14 Feb 2005 12:10:05 -0000 Received: from [203.9.107.238] (tenring.andymac.org [203.9.107.238]) j1EAvF0g035742; Mon, 14 Feb 2005 21:57:15 +1100 (EST) (envelope-from andymac@bullseye.apana.org.au) Message-ID: <42108243.9030800@bullseye.apana.org.au> Date: Mon, 14 Feb 2005 20:49:39 +1000 From: Andrew MacIntyre User-Agent: Mozilla Thunderbird 1.0 (OS/2/20041207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Schultz References: <1108277558l.86500l.0l@BARTON> <20050213082128.GA68307@VARK.MIT.EDU> In-Reply-To: <20050213082128.GA68307@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: Jason Henson Subject: Re: malloc vs ptmalloc2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 12:10:12 -0000 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