Przemyslaw Skibinski

I don't think that results at https://github.com/inikep/lzbench are very important. The results depends on CPU, compiler, file type etc. The idea behind `lzbench` is that everybody can do their own...

Most of compressors should work fine on Android. The following test shows that `lzbench` works fine with `aarch64` (`ARMv8`) under `QEMU`: https://travis-ci.org/github/inikep/lzbench/jobs/660067132?utm_medium=notification&utm_source=github_status

Hi, this is not an error in `lzbench` but in `tornado` compressor (level 1 compression has issues with uncompressible files). You can skip the issue with: ``` ./lzbench -b4096 -etornado...

I'm not interested in `zopfli` by myself but I accept contributions (pull-requests) with additional compressors.

Hi, these are good ideas. The memory consumption is hard to do as each compressor uses it's own memory allocation which needs to be tracked.

It should be fixed with this commit: https://github.com/inikep/lzbench/commit/735da23eec93040a5bd3c60117756acc54580eef The `-r` must be specified because currently there is no way to process files in a directory without processing subdirectories.

Time is measured with: QueryPerformanceCounter for Windows mach_absolute_time for macOS clock_gettime(CLOCK_MONOTONIC) for Linux

Currently it works well (for lzbench and TurboBench) because we set `realtime` priority and assume that we are using only a single core. `Glza` is only compressor that uses multi-core...

Please try `-m` option which splits large files into parts. You can also compress a large file in blocks/chunks with `-b` option.

Currently `-eall` uses `zstd,1,2,5,8,11,15,18,22`. I would add `-1`, `-3`, `-5` but it depends if there is a big difference in speed/ratio between these levels.