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

[Peter Wemm]

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 at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5