Date: Tue, 9 Dec 2003 18:13:28 -0800 From: Sean Chittenden <seanc@FreeBSD.org> To: Kris Kennaway <kris@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: <20031210021328.GH16547@perrin.nxad.com> In-Reply-To: <20031210012353.GC30989@hub.freebsd.org> References: <200312072352.hB7Nqsw6011333@repoman.freebsd.org> <20031208190305.GA956@cirb503493.alcatel.com.au> <20031209070020.GC59494@perrin.nxad.com> <20031209165827.GA18959@dragon.nuxi.com> <3FD65A5D.6060407@acm.org> <20031210001724.GB16547@perrin.nxad.com> <20031210012353.GC30989@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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 -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031210021328.GH16547>