GPLv3 migration reminder
schmorp at schmorp.de
Wed Dec 19 02:12:34 CET 2007
On Tue, Dec 18, 2007 at 11:28:15AM +0100, Simon Josefsson <simon at josefsson.org> wrote:
> different than for file compression -- the most important factor is
> probably de-compression speed and memory footprint. LZO claims to have
> good properties here. How does lzf stand?
Much faster and much less memory used (for compression, just the
hashtable, for decompression no extra memory is required except for
input and output buffers and the code is very small), except when lzo
offers a pure assembly implementation (liblzf has a similar but simpler
representation, but is only available as portable C code).
Of course, compressed size is larger for liblzf than for about any lzo
mode, but thats the trade-off.
For example, a tar of my /bin (10506240 bytes), compression, on my amd64:
time lzop -1 <x.tar |wc -c
time lzf <x.tar |wc -c
this is not a very good test, as buffering and other things only the
commandline tools do have quite some overhead, but gives a rough
lzf is tunable for speed and compression in various ways, the above is the
default (medium speed).
lzf is especially nice for repeated compressions (its not a stream
compressor), as it doesn't need to set up its internal state.
> It would be interesting to run tests on a few different compression
> libraries to see how they compare for network compression...
Every benchmark is always sooo surprising :->
What is not clear to me is how gnutls would use liblzf, purely as
in-memory cache, or would it also use it for network traffic (in which
case, wouldn't it have to support lzo for backwards compatibility, and
would it then not just be able to talk to itself?)
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / pcg at goof.com
More information about the Gnutls-devel