Date: Thu, 7 Nov 2002 09:37:21 -0500 (EST) From: Gary Thorpe <gathorpe79@yahoo.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: freebsd-arch@freebsd.org Subject: Re: malloc(9) performance Message-ID: <20021107143721.74192.qmail@web11201.mail.yahoo.com> In-Reply-To: <20021107055331.GA63812@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- David Schultz <dschultz@uclink.Berkeley.EDU> wrote: > Thus spake Nate Lawson <nate@root.org>: > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021107143721.74192.qmail>