From owner-freebsd-arch Thu Nov 7 6:37:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5A5C37B401 for ; Thu, 7 Nov 2002 06:37:21 -0800 (PST) Received: from web11201.mail.yahoo.com (web11201.mail.yahoo.com [216.136.131.171]) by mx1.FreeBSD.org (Postfix) with SMTP id 54A0143E6E for ; Thu, 7 Nov 2002 06:37:21 -0800 (PST) (envelope-from gathorpe79@yahoo.com) Message-ID: <20021107143721.74192.qmail@web11201.mail.yahoo.com> Received: from [24.114.70.137] by web11201.mail.yahoo.com via HTTP; Thu, 07 Nov 2002 09:37:21 EST Date: Thu, 7 Nov 2002 09:37:21 -0500 (EST) From: Gary Thorpe Subject: Re: malloc(9) performance To: David Schultz Cc: freebsd-arch@freebsd.org In-Reply-To: <20021107055331.GA63812@HAL9000.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --- David Schultz wrote: > Thus spake Nate Lawson : > > I understand this. I only posted because I was surprised by the > 18x > > difference between 1 large malloc(3) and that plus two small > malloc(3)'s. > > > > > has to do semi expensive system calls to do its job. > > > > I don't see how the syscall would result in 18x degradation, > especially > > since once the brk() happens, the allocation should just be a list > > access. But I am not familiar with the internals of either > malloc(3) or > > (9). > > When you make a single small allocation with malloc(3), you're > effectively making a page allocation and then fiddling with a > bitmap of free space within that page, so it takes longer than > allocating full pages. The effort required is inversely > proportional to the size of the allocation for sub-pagesize > allocations. The routine could be micro-optimized, e.g. by > replacing 'while (i >>= 1) j++;' with 'ffs(i & i-1);' and by > adding a hint to speed up searching of the bitmap, but I'm > skeptical that these tweaks would be worthwhile. I don't know > anything about malloc(9), but I suspect it is orthogonal. Shouldn't page allocations be minimized to the situation where there is not enough memory in partially free pages to satisfy the request? If this is the case, then the first small malloc() would have to allocate a page and set up bitmaps, but subsequent malloc()'s would only have to manipulate the bitmap as long as they can hold in the same page (slower than page-aligned malloc()'s when a new page is needed but it should be otherwise faster). Since the kernel also does internal management of its address space, would the same logic apply? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message