From owner-freebsd-current@FreeBSD.ORG Wed Jan 7 04:43:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 340DF16A4CE; Wed, 7 Jan 2004 04:43:10 -0800 (PST) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC5643D31; Wed, 7 Jan 2004 04:43:08 -0800 (PST) (envelope-from Alexander@Leidinger.net) Received: from fwd02.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1AeCz6-0006dM-00; Wed, 07 Jan 2004 13:40:28 +0100 Received: from Andro-Beta.Leidinger.net (Z4a6P8ZUQeIYwlZYFOWpM-SmPAJA653IdEJSy6EcpRjiUBvNAe5jr-@[217.229.210.170]) by fmrl02.sul.t-online.com with esmtp id 1AeCyE-25XPRA0; Wed, 7 Jan 2004 13:39:34 +0100 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i07CdKJb021840; Wed, 7 Jan 2004 13:39:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (netchild@localhost [127.0.0.1]) i07CdU9g017349; Wed, 7 Jan 2004 13:39:30 +0100 (CET) (envelope-from Alexander@Leidinger.net) Date: Wed, 7 Jan 2004 13:39:30 +0100 From: Alexander Leidinger To: Peter Jeremy Message-Id: <20040107133930.47eb851b@Magellan.Leidinger.net> In-Reply-To: <20040107004916.GB25474@server.vk2pj.dyndns.org> References: <200401061536.i06FadY90540@alogis.com> <20040106171740.201f6581@Magellan.Leidinger.net> <20040107004916.GB25474@server.vk2pj.dyndns.org> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: Z4a6P8ZUQeIYwlZYFOWpM-SmPAJA653IdEJSy6EcpRjiUBvNAe5jr-@t-dialin.net cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: perl malloc slow? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 12:43:10 -0000 On Wed, 7 Jan 2004 11:49:16 +1100 Peter Jeremy wrote: > >You need to make a context switch for every malloc call. > > This isn't true. There are no circumstances under which phkmalloc > requires a context switch. Since Unix uses a pre-emptive scheduler, > a context switch may occur at any time, though it is preferentially > performed during system calls. Yes, wrong wording by me. I was trying to say it has to enter the kernel via a syscall. In the worst case for every malloc()/free(). And entering the kernel is expensive, compared to not entering the kernel and doing stuff in userland. > If the free memory pool managed by phkmalloc has insufficient space to > fulfil the request, or is excessively large following a free() then it > will use brk(2) to allocate/return additional memory. The kernel may > choose to schedule an alternative process during the brk() call. With a sufficiently large amount of syscalls the wall clock time will increase. And that's what Holger reported (further reading your mail: not because of this fact, but I hadn't digged into the perl module). [reason why the perl module behaves poorly] > It's not clear why the builtin perl malloc is so much faster in this > case. A quick check of the perl malloc code suggests that it uses a > geometric-progression bucket arrangement (whereas phkmalloc appears to > use page-sized buckets for large allocations) - this would > significantly reduce the number of realloc() copies. This is IMHO the right allocation algorithm for such programs (at least I don't know of a better one and I've seen it in several places where you can't guess the amount of memory you need). I'm sure the perl developers tuned the perl_malloc() with real world perl programs. Maybe this kind of behavior is typical for a lot of perl programs. Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7