tansy

> The list shows what options are supported by given compressors in lzbench. Exactly. \`-T' is provided by the bench not by the codec, so it has nothing to do...

Pool threading is supported for every codec, so it's not any specific to this or that codec. I'll think of it yet.

You could put that 'cmakefile' in a gist, so one could get and test it, to see what is the actual problem. You could also fork and brach the repository,...

> uname -m — but even that would be wrong, because the package could be built with -m32 for 32-bit userland. Then it would return correct value for that (architecture)....

@Sanmayce: as far as I know Nakamichi is your codec. Would you mind to add simple statement what the licence of the software is? Practically all other codecs have their...

> lzav -2 decompressing faster than lzav -1 is a bit suspicious to me. There is nothing 'suspicious', not surprising about it. Exactly same relation applies to lz4hc, zlib, lzma,...

> The contradiction in your statement is exactly about having "more matches" that increases the amount of "branching" per byte in the stream. Brachylogy. You can always test what is...

> Thanks for the links to the benchmarks. You're welcome. [Here](https://dev.azure.com/inikep/lzbench/_build) are all of them. > However, not too useful as there is no machine info. That's the problem with...

> Why make it so aggressive, eh? ? > CI tests use 8 MB files. 7, to be more precise. It uses it's own executable as input (`$ ./lzbench -eall...

> Someone should have pointed this out ca. 2010 Ca. 2010 i didn't know about this program. I'm sure that 95% of present users didn't know it either. > before...