GPLv3 migration reminder

[Simon Josefsson]

Marc Lehmann <schmorp at schmorp.de> writes:

> 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.

Interesting, thanks for info.

>    lzop: 0m0.056s
>    lzf:  0m0.048s
>
> 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
> indication.

Right, that's why I was interested in doing some real TLS-related
benchmarks...

> 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?)

Network traffic.  Currently DEFLATE (libz) is supported by TLS, and
there is one patented alternative (LZS) specified.  We support LZO too,
even though it isn't standardized.  I don't think LZO in TLS has any
wide deployment, and in any case, there is nothing that says we can't
support both LZO and LZF.  Doing so would make it easier to perform
benchmarks.

Still, I guess that there are more higher priority projects in GnuTLS..
but compress benchmarks seems like an interesting thing to do.

/Simon