Date: Wed, 10 Dec 2003 07:35:51 -0800 From: Peter Wemm <peter@wemm.org> To: Sean Chittenden <seanc@FreeBSD.org> Cc: Tim Kientzle <kientzle@acm.org> 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 Message-ID: <20031210153551.974BE2A7EA@canning.wemm.org> In-Reply-To: <20031210021328.GH16547@perrin.nxad.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031210153551.974BE2A7EA>