From owner-freebsd-current@FreeBSD.ORG Thu Jan 8 00:03:45 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 4B3DF16A4CE; Thu, 8 Jan 2004 00:03:45 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1184543D53; Thu, 8 Jan 2004 00:03:42 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i0883Z7B033803; Thu, 8 Jan 2004 19:03:35 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i0883YS8033802; Thu, 8 Jan 2004 19:03:34 +1100 (EST) (envelope-from peter) Date: Thu, 8 Jan 2004 19:03:34 +1100 From: Peter Jeremy To: Poul-Henning Kamp Message-ID: <20040108080334.GK25474@server.vk2pj.dyndns.org> References: <20040107133930.47eb851b@Magellan.Leidinger.net> <31178.1073481069@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31178.1073481069@critter.freebsd.dk> User-Agent: Mutt/1.4.1i 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: Thu, 08 Jan 2004 08:03:45 -0000 On Wed, Jan 07, 2004 at 02:11:09PM +0100, Poul-Henning Kamp wrote: >One of the assumptions I made ten years ago, was that we would expose >more of the possible VM gymnastics to userland and in particular it >was my expectation that it would be cheap for a process to do some >sort of page-flipping or page-exchange. > >This has not materialized in the meantime, and VMwizards have >generally been a lot less than enthusiastic about it when I have >tried to coax them into providing this sort of thing. Maybe we need a mremap(2) implementation. This would allow cheap realloc(), though phkmalloc would need to be modified to use mmap() rather than [s]brk() for heap allocation. (We need mremap() for the Linux emulation anyway). I don't know how easy this would be to implement - I suspect not very, and excessive use of mremap() could severely fragment a processes address space (which could wreak havoc with the page tables). >VM systems on the other hand, operates on a page level, and modern >code would be much better off like this: > > > l = PAGE_SIZE; > p = malloc(l); > for (;;) { > [...] > /* Damn */ > l *= 16; > p = realloc(p, l); > [...] > } > /* Now trim */ > p = realloc(p, strlen(p)); > >(For some value of 16.) Does this behaviour belong in the application or the malloc implementation? I believe most other realloc implementations use a exponentially increasing bucket size so the application effectively gets this behaviour (with '16' typically being either 2 or roughly sqrt(2)) whether the application uses linear or exponential size growth. Peter