Skip to content

Instantly share code, notes, and snippets.

@cellularmitosis
Last active July 12, 2020 00:34
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save cellularmitosis/7b2bc60f1ca20913732fbb530cf30668 to your computer and use it in GitHub Desktop.
Save cellularmitosis/7b2bc60f1ca20913732fbb530cf30668 to your computer and use it in GitHub Desktop.
Comparing lzo compression levels (and gzip)

Blog 2020/7/7   (retroactively posted on 2020/7/10)

<- previous | index | next ->

Comparing lzo compression levels (and gzip)

In preparation for writing Janet bindings for LZO, I took a look at how lzop behaves at various compression levels (-1 through -9).

To do this, I wrote a simple Janet script called zbench.

Because lzop is so fast, I ran this script on the slowest hardware I had on hand (a 266MHz NSLU2) to exaggerate any differences. For reference, I've also included gzip results.

The results:

Compression 'user' time   (4MB of Linux source, 266MHz ARMv5)

Compression ratio    (first 4MB of Linux source tarball)

Remarks:

  • lzop -1 through lzop -6 are the same
  • lzop -7 is slower than gzip -9, with ratio equivalent to gzip -3
  • if you need more compression than lzop -6, gzip -1 has a significantly better ratio at the cost of 3x the run time.
  • gzip past -6 shows almost no improvement on ratio

I could think of only the following use-cases for lzop -7 through lzop -9:

  • lzop is required by the system
  • decompression speed trumps every other concern
  • you have zero memory available for decompression (e.g. a microcontroller)

So, at least for the use-base of compressing Linux source code, these are points of interest:

  • lzop -1 through -6
  • gzip -1
  • gzip -6
  • lzop -9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment