cvs commit: src/sys/i386/conf GENERIC src/sys/alpha/confGENERIC src/sys/sparc64/conf GENERIC src/sys/amd64/conf GENERIC src/sys/pc98/conf GENERIC

[Tim Kientzle]

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.

I've been spending some time recently with the libbz and libz
compression functions (testing the auto-detect and extract features of
libarchive), so I've gotten pretty familiar with the relative time hit
for these two libraries.  The libbz library is a big time sink.
(Which isn't too surprising, given the two algorithms; there was a good
article in Dr. Dobb's a couple of years back describing the BZip
algorithms.  The 'deflate' algorithm used by gzip is described in
an RFC.  Read them and it's pretty obvious why bzip2 is so much
slower.  It's doing a lot more work.)

  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

Absolutely.  It's still a good idea.

Tim