From owner-freebsd-arch Wed Nov 6 21:53:36 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 C468E37B401 for ; Wed, 6 Nov 2002 21:53:35 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id C421743E3B for ; Wed, 6 Nov 2002 21:53:34 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gA75rVC4064636; Wed, 6 Nov 2002 21:53:32 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gA75rVRt064635; Wed, 6 Nov 2002 21:53:31 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 6 Nov 2002 21:53:31 -0800 From: David Schultz To: Nate Lawson Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: malloc(9) performance Message-ID: <20021107055331.GA63812@HAL9000.homeunix.com> Mail-Followup-To: Nate Lawson , Jeff Roberson , arch@FreeBSD.ORG References: <20021106163703.X1374-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message