Pull to refresh

xz — сила сжатия LZMA уже в твоей консоли

Data compression
Многие наверное уже знают про утилитку для компрессии/декомпрессии xz. Но еще больше не знают. Поэтому написал этот ознакомительный топик.

xz — формат сжатия данных, наряду с gzip, bzip2 вошедший в gnu-шные приложения.
Использует алгоритм LZMA, тот же что и в 7z, а это значит что можно сильнее сжать многие виды данных, типа текста, бинарные еще не сжатые данные по сравнению с стандартными, упомянутыми выше.
xz используется в новом rpm 4.7.2 для компрессии архивов .cpio в rpm-пакетах (используется с Fedora 12).
В ArchLinux вообще используется .tar.xz в качестве пакета.
В GNU tar появились опции -J --lzma, которые исполняют туже роль что и -z для gzip, -j для bzip2

Плюсы:
Высокая степень сжатия

Минусы:
большое потребление ресурсов:
cpu time (и собственно времени сжатия)
памяти (настраивается, но все равно больше чем gzip, bzip2).
В частности xz при --best aka -9потребляет до 700мб! при компрессии и 90мб при декомпрессии

Фичи:
Потребление большого объема памяти немного ограничивается предварительным вычислением имеющихся ресурсов.
интеграция в GNU tar
работа с потоками
опционально: progressbar через --verbose

Не хочется сильно засорять ознакомительный топик графиками и прочим, но без этого не обойтись:
Сделал банальный забег gzip, bzip2, xz на предмет степени сжатия, потребления времени. также в качестве гостя принимат участие WinRar (хоть и хмельной, под wine, но всетаки показал отличные результаты)


у этого рисунка отличная кликабельность
В качестве тестовых данных взял развернутую ветку федориного ядра 2.6.27, собрал её в tar — объемом 292мб, и провел замеры. По вертикали уровень компрессии (разы), по горизонтали — кол-во потраченного времени.

xz ужал этот файл от 4,8 до 6,9 раз.
gzip 3,6 — 4,5
bzip2 4,5 — 5,6
winrar 4,5 — 6,7

Получаем 4 квадрата:
Нижний левый — медленные и слабожмущие: gzip и winrar fastest.
Верхний левый: выигрышное соотношение сжатие/время: немного лучше себя показывает bzip2, xz на 1 и 2м уровне сжатия, и
Верхний правый: настоящий прессовый механизм: доллго но очень сильно сжимающий xz
В нижнем правом: никого нет, да и кому нужен долгоработающий и слабосжимающий архиватор?

Но вообще координатная сетка не удачно подобрана: как мы оцениваем время? категориями! например быстро — 10-20 секунд, средне от полминуты до минуты, больше 2 минут — это долго.
так что логарифмическая шкала тут нагляднее:


А если если оценить их как сжатие потока, на моем Core2Duo E6750 @ 2.66GHz,
то получился такой вот график:

т.е. использовуя в качестве сжималки конвеера gzip -1 или gzip -4, в 100мбитной сети можно гонять до 25мбайт/сек нежатых данных. (несколько раз проверял — gzip -4 почему-то дает больший профит чем -3 или -5)
cat /some/data | gzip -1c | ssh user@somehost -c "gzip -dc > /some/data"
xz можно использовать в таком лишь на каналах <8мбит,

Очевидный вывод ( При содействии K.O. )

xz — в виду потребления ресурсов занимает нишу архиваторов компрессоров, там где может играть большое значение степень сжатия, и есть достаточно вычислительного ресурса и ресурса времени. т.е. различного рода бекапы/архивы, дистрибутивы (rpm же, tar.xz в archlinux). Или данные очень легко подвергающиеся сжатию: логи, таблицы с текстовыми-цифровыми данными csv, tsv, которые не предполагается изменять.

P.S. Как бы не радовался за xz, в разумности потраченных усилий WinRar Wins.
Tags:xzсжатие данныхсжатиеgzipbzip2архиваторархиваторы
Hubs: Data compression
Total votes 15: ↑11 and ↓4+7
Views10K

Popular right now