From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 14 13:05:29 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 91AD916A54C for ; Mon, 14 Feb 2005 13:05:29 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6BAA43D3F for ; Mon, 14 Feb 2005 13:05:06 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j1ED4pd3055358; Mon, 14 Feb 2005 08:04:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j1ED4pZ8055357; Mon, 14 Feb 2005 08:04:51 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Mon, 14 Feb 2005 08:04:50 -0500 From: David Schultz To: Andrew MacIntyre Message-ID: <20050214130450.GA55300@VARK.MIT.EDU> Mail-Followup-To: Andrew MacIntyre , Jason Henson , freebsd-hackers@FreeBSD.ORG References: <1108277558l.86500l.0l@BARTON> <20050213082128.GA68307@VARK.MIT.EDU> <42108243.9030800@bullseye.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42108243.9030800@bullseye.apana.org.au> 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 13:05:30 -0000 On Mon, Feb 14, 2005, Andrew MacIntyre wrote: > 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. Right, databases, language runtimes, and the small set of other applications for which it really matters usually have their own special-purpose allocators. I was counting on that when I said that replacing malloc() is unlikely to make a big difference. (One could argue, of course, that it's unfortunate that applications need to do so.)