[PATCH 2/2] (g)unzip: Optimize inflate_codes()

[Joakim Tjernlund]

Rob Landley <rob at landley.net> wrote on 2010/02/13 19:08:01:
>
> On Saturday 13 February 2010 03:22:09 Joakim Tjernlund wrote:
> > I think than modern HW will not benefit as much as slower embedded HW
> > do you have any?
> > It can also be that gzip is so unoptimized to begin with that my
> > patch won't matter much.
> > What version of gzip is bb gzip based on? I got the impression that
> > bb gzip also have some local hacks.
>
> The deflate algorithm is very much optimized for speed.  It's used for things

The algorithm yes, but the gzip impl. sucks I think. zlib claims 20% faster inflate
and 50% faster crc32 in its 1.2.x series and gzip is based on an earlier version
of zlib.

> like the ssh compress option, apache's mod_deflate, and so on.  Things where
> being able to squash a text stream down to maybe 10% of its original size is
> really cool, but you're doing so in the spare cycles of an otherwise loaded
> system and trading off cpu vs bandwidth on a machine that has gigabit ethernet.
>
> Also things like openoffice use a text file format and then pipe it through gzip
> to save it, because their format can be some verbose xml nightmare with little
> consequence if it compresses trivially.  Doesn't have to be all that efficient,
> it makes saving _faster_.  (But then so does having a SATA drive instead of
> pre-DMA PATA IDE...)  If saving your word processing document pegs the CPU for
> 15 seconds, that's not nearly as attractive...

and how does this relate to my patch?

 Jocke