From owner-cvs-src@FreeBSD.ORG Wed Dec 10 07:35:52 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7CAC16A4CF; Wed, 10 Dec 2003 07:35:52 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF00F43D2E; Wed, 10 Dec 2003 07:35:51 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 974BE2A7EA; Wed, 10 Dec 2003 07:35:51 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Sean Chittenden In-Reply-To: <20031210021328.GH16547@perrin.nxad.com> Date: Wed, 10 Dec 2003 07:35:51 -0800 From: Peter Wemm Message-Id: <20031210153551.974BE2A7EA@canning.wemm.org> cc: src-committers@FreeBSD.org cc: obrien@FreeBSD.org cc: cvs-src@FreeBSD.org cc: Kris Kennaway cc: Scott Long cc: cvs-all@FreeBSD.org cc: Tim Kientzle Subject: Re: cvs commit: src/sys/i386/conf GENERIC src/sys/alpha/conf GENERIC src/sys/sparc64/conf GENERIC src/sys/amd64/conf GENERIC src/sys/pc98/conf GENERIC X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2003 15:35:52 -0000 Sean Chittenden wrote: > > > > 2) bunzip2 is about 10x slower than gunzip on my system. > > > > (Decompressing the openoffice tarball: 42s vs. 4s) > > > > > > 10% speed vs. 20% disk on install CDs. *shrug* > > > > He said 1000%, not 10%. > > Hrm... 11sec vs 1:15. Not something I'd consider a deal breaker for > the concept though. This is odd. From gprof: > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 55.5 1.32 1.32 34720 0.04 0.04 __sys_write [8] > 22.4 1.85 0.53 2597 0.20 0.20 _read [15] > > I wonder if there isn't something that `bzip2 -d` is doing that's got > this so slow. It takes cat(1) less than a sec to send the data to > /dev/null. I may dive into this some as it may be the implementation > of bzip2 that's the problem and not the algorithm. Anyway, Kris/Tim, > you were right... 1000% slower, but not something I'd complain about > given we're talking about time differences in terms of a minute. > It's still faster than extracting a .CAB. :) -sc Looking at ktrace output.. gzip uses a read blocksize of 32K and a write blocksize of 16K. bzip2 uses a read blocksize of 16K and a write blocksize of 4K. At the very least, its doing twice as many read syscalls and four times as many write syscalls. That probably isn't helping. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5