Date: Wed, 6 Nov 2002 21:53:31 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Nate Lawson <nate@root.org> Cc: Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG Subject: Re: malloc(9) performance Message-ID: <20021107055331.GA63812@HAL9000.homeunix.com> In-Reply-To: <Pine.BSF.4.21.0211061429500.16185-100000@root.org> References: <20021106163703.X1374-100000@mail.chesapeake.net> <Pine.BSF.4.21.0211061429500.16185-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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?20021107055331.GA63812>