Бенчмарки — Бесхитростное оффлайновое сравнение нескольких программ сжатия

Тест без претензий на полноту охвата, строгость методики и знание алгоритмов. Скорее всего, будет редактироваться по мере уточнения деталей и для расширения общей картины.
Таблица с моими результатами: http://paste.pro/1713084.

В основном, взяты компрессоры, устанавливающиеся из штатных репозиториев распостранённых дистрибутивов.
Современная классика gzip (библиотека называется zlib), более свежий bzip2, ещё свежее XZ ( lzma-2), и некоторое количество программ с буквой Z, чьи суффиксы реже попадаются на глаза, но весьма заслуживающих внимания. Интерес будет преимущественно к быстрым компрессорам, отлично жмущие, но медленные я рассматривать не буду.
XZ сжимает файлы существеннно лучше, чем bzip2 и, тем более, gzip, но делает это медленно. lzop жмёт очень быстро, но слабее. Кроме XZ, lzma реализован в компрессоре lzip. Он ориентирован на возможность независимого восстановления файлов из архива, и к нему есть многопоточная реализация plzip. В настоящий момент сделана и многопоточная реализация gzip - pigz. Многопоточный bzip2 называется pbzip2.
В 1990х годах А. Триджелл с соавторами придумал программы rsync и rzip. Развитием rzip стал lrzip, написанный Коном Коливасом, автором известного bfq-планировщика, призванного улучшить отзывчивость линукс-десктопов годы назад, но так и не включенного в апстрим. В lrzip в качестве бэкендов добавлены все вышеупомянутые алгоритмы ( rzip использовал bz2).

Наконец, есть семейство очень быстрых компрессоров. Реально очень быстрых. Вот ссылка на сравнение сжатия некоторых данных ( DirectX SDK samples): http://altdevblogaday.org/2011/04/22/survey-of-fast-compression-algorithms-part-1/. Из него я позаимствовал легкодоступные quicklz ( в таблице qpress), lzf и fastlz ( в таблице 6pack), а также lz4*. Недавно отрытый Google под BSD-2 лицензией snappy уже доступен как библиотека libsnappy1 в Дебиане и Убунте.

В жизни компрессоров, кроме более-менее разовых событий обработки файлов, встречаются возможности подключения zlib- и lzo- сжатия в файловых системах btrfs (zlib с 2.6.29 ядра, lzo - с 2.6.38 ядра) и reiser4 ( а также ZFS с zlib и lzjb вместо lzo). Обзоры Фороникса, касающиеся сжатия в btrfs: lzo на HDD, zlib на SSD.

Свои тесты я делал в оперативной памяти на tar-архиве размером ~250 MB, состоящем из нескольких проектов в латехе ( тексты, графики), документов разных форматов и zip-архива ~ 100 MB с рисунками ( jpeg). При этом был запущен браузер, временами я что-то открывал/закрывал.
Время снималось командой /usr/bin/time, скорости получались делением исходного размера на время работы. Там, где не проставлены загруженности процессора ( %CPU), они или 99 или около того. Значения более 100 означают, что алгоритм успешно освоил многоядерность - максимум 400 для всех 4х ядер ( процессор Phenom II X4 905e). В первой колонке таблицы показаны отношения размеров несжатого файла к сжатому.

Итак, что мы имеем:
xz и lzip никуда не торопятся. Несмотря на это, разница в сжатии с bz2 мала ( на данном наборе файлов). Преимущество xz - в распаковке на приличной скорости: в 4 c лишним раза быстрее bz2.

pigz и впрямь многопоточный, пакует всеми 4 ядрами, распаковывает где-то двумя. Опция --rsyncable пока что не реализована. plzip использует многоядерность менее эффективно, но всё же в разы улучшает скоростные показатели lzip: жмёт быстрее xz в 2 раза.

Определённо, жжёт lrzip. 250 МБ отлично помещаются в память, давая развернуться препроцессингу. На файлах, не влезающих в оперативку, скорости бы упали многократно из-за необходимости нескольких проходов. Здесь же использование легчайшего lzo с параметром 1 даёт сжатие уровня bz2 на скорости, превышающей gzip, при промежуточной между lzma и gzip скорости декомпрессии. Подключение же lzma ( по умолчанию) или gzip ( -g) даёт намного лучшее сжатие при сохранении скорости в разы большей, чем у lzma, а скорость декомпрессии lrzip+gzip оказывается на уровне gzip.
lrzip с параметром -n ограничивается только rzip-препроцессингом, как видно, самостоятельного интереса этот режим не представляет. Попытки раздельной пост-обработки бэкендами дали существенный проигрыш по времени.
Можете посмотреть на бенчмарки от автора: http://ck.kolivas.org/apps/lrzip/README.benchmarks

В стане быстрых компрессоров шустрят lz4 ( самый быстрый в один поток) и многопоточный qpress. Увеличение числа потоков ( по умолчанию 2) даёт тот же самый файл за ощутимо меньшее время - 4 потока оказываются в 3,5 раза быстрее одного, а 3 потока quicklz сжали файл быстрее однопоточного вычисления хеш-суммы md5. Скорость декомпрессии обгонит чтение большинства SSD-дисков. Впрочем, для многих систем с не слишком топовыми дисками окажутся стремительными и lzf, и lzo. При этом lzo совершенно точно не стоит использовать с компрессией --best (8,9), и, скорее всего, предпочтительна --fast (1), дабы не притормаживать на плохо сжимаемых данных (уже сжатые мультимедиа, архивы и т.п.). В моём наборе наглядная разница есть в lrzip-тестах. Слабо выглядел fastlz ( 6pack), возможно, затупил на внутреннем zip-архиве ( Да и вообще, что-то на русском название его исполняемого файла на "брак" смахивает).

Как можно заключить из обзора http://fastcompression.blogspot.com/p/compression-benchmark.html, есть и другие достойные внимания компрессоры. FreeArc - похож на самый быстрый из субмаксимально сжимающих программ.

* lz4 был успешно скомпилирован после обмена сообщениями с автором программы.

**Замечание об опциях. gzip, pigz, xz, lzip , plzip, bzip2, lzf по умолчанию удаляют исходный файл. У большинства отменяет удаление опция -k ( --keep), gzip для этого нужно отправлять в stdout опцией -с и синтаксисом вида gzip -c input > output или использовать в связке с tar. Tar обеспечивает работу всех этих программ с директориями, см. его описания. lrzip аналогично предоставляет команду lrztar.