Сжимаем данные почти до предела архиватором 7-Zip и почему аналог от мира Linux проиграл

Работая над своим методом установки софта (Installer-SH) для дистрибутива Chimbalix я провёл некоторые оптимизации, и выиграл ощутимые ~16% (в зависимости от данных) относительно линуксоидного стандартного tar.xz формата:

Совершенствую новый способ распространения ПО для дистрибутива Chimbalix

Однако это ещё не предел... Хотя куда там, разве можно достичь предел? Что-то сомневаюсь в этом, так что просто поэкспериментируем со сжатием.

В качестве подопытных будут участвовать две игры, это FlatOut и FlatOut 2, в оригинальном формате установочных пакетов они занимают целых 7.7 ГиБ места на диске, и я подумал, а почему бы не "оптимизировать", ведь эти игры мне далеко не всегда нужны, а место занимают, да и скачивать их постоянно из платформы gog.com слишком накладно, если вдруг нужны для тестов каких или просто поиграть:

Так вот, чтобы сжать игры, сначала нужно избавить их от оригинальных установочных пакетов, ибо сжатое сжимать весьма сомнительная идея... Это подразумевает потерю оригинальных установочных файлов, которые бы создавали ярлыки в меню, но мне это и не нужно, ибо главное портативность и доступ к игре в любой момент просто распаковав архив:

Кстати, мой способ установки приложений для Chimbalix (Installer-SH) позволяет вручную без установки распаковать архив с приложением, но не будем отходить от темы.

В чём сложность? Некоторые вероятно уже заметили, у меня как Windows версии игр, так и "условно линуксоидные", это когда людей вводят в заблуждение оборачивая Windows игры в Wine костыли, называя эти фальшивки "играми для Linux"...

-

Почему аналог от мира Linux проиграл

Прежде чем начнём эксперименты с 7-Zip форматом, посмотрим на "аналог" от мира Linux, а именно tar.xz, хотя смотреть тут особо нечего, tar просто пакует все файлы и папки в архив без сжатия, а xz сжимает, ибо умеет только один файл сжимать, среди параметров ничего интересного нет:

Важно заметить, как и 7-Zip, xz формат относится к группе "LZMA" форматов, именно потому я назвал его "аналогом", но увы, он ужасен, как и линуксы в Desktop сегменте...

Да, оно работает, и даже сжимает, но сколько времени уходит на сжатие... А ведь у меня не то чтобы очень слабый ПК, нет, вполне себе бодрый Ryzen 7 2700X с 64 ГБ ОЗУ, да, хоть его частота и ограничена значением 3.6 ГГц по всем ядрам (для тестов нужно обычно), но это далеко не слабый процессор:

Однако линуксоидному tar.xz плевать, настолько, что архивация 3.7 ГиБ данных в этот формат заняла 21 минуту 33 секунды, и это при стандартных настройках "как есть", обычное сжатие:

Итоговый размер архива получился около 1.7 ГиБ, отлично, это будет отправной точкой в наших экспериментах со сжатием 7-Zip, чтобы было с чем сравнивать, пойду сразу же поставлю чтобы архивировалась вторая часть игры в tar.xz, брр...

Главное не закрыть случайно окно терминала с результатами затраченного времени, когда оно закончит архивацию, ну и случайно не запустить ничего тяжёлого в плане расхода ресурсов системы:

Итого 36 минут 55 секунд было затрачено на сжатие 6.4 ГиБ данных, причём сжалось так себе:

Отлично, начало положено, теперь можно перейти к экспериментам с 7-Zip архиватором.

-

--

7-Zip

Использовать буду статически скомпилированную версию 7-Zip 24.07 x64, причём в обязательном порядке буду задействовать флаг "snl", что сохраняет символические ссылки (а они есть среди файлов):

           

Как бы иронично это не звучало, но разработчики линуксоидских архиваторов (Arc, Engrampa, File-Roller) мало того не предоставили практически никаких настроек в интерфейсе пользователя, но и по умолчанию не сохраняют символические ссылки в архивах 7-Zip, хотя казалось бы, Linux! Как без символических ссылок!

Интересно, почему это линуксы никому в здравом уме не нужны на обычных ПК и ноутбуках? Даже не знаю... Хотя стоит заметить, есть архиватор PeaZip, по скриншотам выглядит вполне отлично, но увы, графический интерфейс сделан на GTK/Qt, и порой умудряется заметно так тормозить на современных системах...

                       

Так что не будем извращаться с линуксоидными, вечно кривыми поделками, и начнём эксперименты с официальной, консольной версией 7-Zip.

Архивируем со стандартными настройками "как есть", архивация первой части игры заняла 2 минуты 11 секунд (25 минут 24 секунды процессорного времени), то есть использовались все 16 потоков моего процессора.

Вторая часть игры архивировалась 2 минуты 45 секунд реального времени, и 37 минут 25 секунд процессорного:

           

Что тут сказать, 7-Zip буквально в 10 раз быстрее сделал ту же самую работу, чем tar.xz, и уровень сжатия со стандартными настройками получился даже немного лучше, хотя и незначительно:

Да, процессорного времени 7-Zip израсходовал больше, но обычному человеку гораздо важнее реальное время за которое сделана работа, и в пределах одной конфигурации формат tar.xz выглядит весьма печально, увы.

Казалось бы, проблема решена! Игры сжаты! Но не спешите, так как FlatOut никогда не выпускался для Linux, а так называемая "игра для Linux" есть ни что иное как Wine костыль + Windows версия игры, то и сами игры практически полностью одинаковы, и одна игра в отдельности весит примерно 1.5 ГиБ, именно столько повторяющейся информации:

           

И если сжать только игру, можно заметить, что одна только игра сжимается всего до 719 МиБ, а значит дубликаты не устраняются при сжатии:

Но к проблеме дубликатов вернёмся позже, давайте сожмём файлы максимальным уровнем mx9, и посмотрим что изменится:

           

Да, конечный размер получился немного меньше, но и времени на архивацию потрачено значительно больше, не очень приятно, однако это всё ещё многократно быстрее, чем справлялся tar.xz...

Следующий логичный этап - увеличение размера словаря, однако важно понимать, чем больше размер словаря - тем больше ОЗУ необходимо для распаковки архива, зависимость прямая, для распаковки архива запакованного со словарём 256 МБ нужно 256 МБ оперативной памяти + на сам архиватор ещё немного.

Так что начнём со значения 256 МБ, что в 4 раза больше, чем при стандартных настройках mx9:

           

Увеличение размера словаря позволило ещё немного выиграть в размере, а при архивации второй части игры процесс даже занял меньше времени, но кардинальных изменений до сих пор нет, увы:

Что же делать... Учитывая что архиватор по умолчанию сжимает в непрерывном блочном режиме, а каждый блок имеет размер до 4 ГБ при параметрах mx9, и он точно умеет устранять дубликаты, ибо на маленьких объёмах это точно работает, ведь уже проверял раньше:

То остаётся только поиграть с параметрами, из интересного был найден параметр "mqs" отвечающий за сортировку файлов по типам перед архивацией, и он по умолчанию отключен... Давайте проверим что из этого выйдет:

           

Наконец ситуация сдвинулась с места! Благодаря сортировке файлов по типам удалось исключить многие дубликаты, тем самым конечный размер архива уменьшился буквально на треть изначального размера в случае первой части игры, однако со второй частью дела обстоят хуже:

И проблема тут в большом размере сжимаемых файлов, их размер больше 1 ГиБ, даже сортировка по типам не помогла устранить дубликаты в данном случае:

Давайте увеличим размер словаря до 2048 МБ!

           

Процесс архивации теперь значительно больше времени занял, и судя по затраченному процессорному времени - использовались не все ядра (оно и видно было в диспетчере задач), однако размер заметно уменьшился, а так же вторая часть игры ощутимо сжалась, это не только значительно быстрее линуксоидного tar.xz, но и значительно сильнее в плане сжатия, хотя казалось бы, оба архиватора используют LZMA2 алгоритм сжатия:

Но... Есть ещё одна хитрость, это параметр "ms", он отвечает за максимальный размер блока, ситуация как с размером словаря, только в другую сторону, для извлечения одного файла нужно распаковать целый блок, а если блок размером с архив...

В общем давайте установим размер блока на уровне 16 ГБ вместо стандартных 4 ГБ, и посмотрим на отсутствие разницы при столь маленьких объёмах архивируемых данных...

Мне не нравятся результаты полученные с помощью LZMA2, давайте перейдём к старому алгоритму сжатия LZMA! Да, вы не ослышались, именно от более нового к более старому, даже несмотря на красивые слова о том, что LZMA2 это тот же LZMA, только лучше сжимает и умеет больше потоков использовать:

И так как первый LZMA действительно не способен использовать много потоков, я не вижу ничего зазорного в том, чтобы одновременно два архива паковать, даже если это даст некоторую погрешность на общий результат, а иначе можно сутками паковать используя всего 1-2 потока...

Хм, неужели tar.xz использует первый LZMA? Что же, поисковик не ответил на мой вопрос, где-то говорят что LZMA2, где-то - LZMA:

А где-то сказано, что XZ поддерживает только LZMA2, вечно в линуксах всё сделано косяк наперекосяк, брр:

Ладно, вернёмся к 7-Zip с обычным LZMA, и тут же выяснилось, что он всё равно значительно быстрее tar.xz, даже несмотря на работу всего в 1-2 потока и суровые параметры сжатия, так что проблема производительности линуксоидных архиваторов явно не в алгоритме сжатия, увы:

           

Да, переход к LZMA положительно сказался на качестве сжатия, и негативно в плане скорости относительно LZMA2, хотя всё равно это было значительно быстрее, чем работает tar.xz:

Давайте увеличим размер словаря до 2048 МБ:

           

Может с первой частью игры и мало выиграл от перехода к LZMA, но в случае второй части разница уже огромна, конечный размер архива вышел около 2.5 ГиБ, когда LZMA2 способен был выдать только 4.1 ГиБ с такими же настройками:

Вот теперь я доволен сжатием, ибо изначально эти две игры занимали 7.7 ГиБ в виде официальных установочных пакетов, а мне удалось перепаковать в размер ~3.3 ГиБ, что на 4.4 ГиБ меньше относительно оригинальных установочных архивов, и на 3.3 ГиБ меньше относительно обычных параметров сжатия 7-Zip и tar.xz.

На этом идеи по сжатию файлов у меня закончились...

Можно конечно увеличивать размер словаря и дальше, с игрой FlatOut 2, вероятно, это сработает ещё, но вот с первой частью уже не прокатит, да и не забываем про тот факт, что размер словаря прямо влияет на требуемое количество оперативной памяти для распаковки архива, так что тут лучше искать "золотую серединку" в зависимости от общего размера и типа файлов.

Менять алгоритмы сжатия тоже вариант, но какие использовать? Я не знаю, обычно только RAR способен тягаться на равных с LZMA, и в редких случаях даже превосходить, но этот формат плохой, ибо проприетарный, zstd еще мельтешит, но увы, на практике оно значительно хуже жмёт, чем старый добрый LZMA.

Хотел я было наглядно продемонстрировать несостоятельность zstd формата, но продемонстрировал несостоятельность линуксоидного архиватора, который завис с утечкой памяти при попытке создать архив, даже не показал окно настроек, видимо зациклился бедолага с линуксоидными символическими ссылками в попытке подсчитать каталоги и файлы, какая жалость:

Ладно, пора бы заканчивать на этом...

-

--

---

Результаты

Традиционно подведём имеющиеся результаты в сводную таблицу, а потом, может быть, и в графики для наглядности.

Первую таблицу было решено сделать простой, чтобы не накосячить, в общем со стандартными настройками преимущество скорости однозначно за 7-Zip, хотя размер не указал, ибо разница небольшая да и "первый блин получился комом":

7-Zip со стандартными настройками явно использовал все ядра процессора (16 потоков), а tar.xz только одно ядро (1 поток), это видно по соотношению реального времени к процессорному невооружённым глазом, и 7-Zip даже больше процессорного времени израсходовал, но тут гораздо важнее реальное время выполнения работы, потому важное выделил зелёным цветом:

Теперь нужно поработать над подробной таблицей, похоже эта работа ничуть не легче, чем сбор результатов и подбор параметров...

Первая подробная таблица относится к игре FlatOut, 12226 файлов на 3797 MiB, итого худший результат за линуксоидным форматом tar.xz, ничего удивительного, 7-Zip с LZMA2 показывает неплохое сжатие, однако без сортировки данных по типам конечный размер выходит не сильно лучше, однако с применением сортировки (параметр "mqs") удалось значительно уменьшить размер архива.

Так же 7-Zip в стандартном режиме LZMA2 самый быстрый, хоть и самый ресурсоёмкий, и эта скорость, к сожалению, теряется при переходе к большому размеру словаря, алгоритм просто не способен задействовать все ядра процессора в таких условиях, но и размер получился близок к минимальному достигнутому...

Но лучшее сжатие оказалось за 7-Zip в режиме LZMA, да, он не способен использовать более двух потоков, отчего работал довольно медленно, хотя всё равно быстрее чем tar.xz, однако количество затраченных ресурсов процессора оказалось самым низким даже по сравнению с tar.xz:

Не знаю каким образом линуксоиды умудрились настолько плохо реализовать tar.xz сжатие, или это 7-Zip 24 версии настолько прокачался, но результаты всё говорят сами за себя:

                       

Далее игра FlatOut 2, лучшее сжатие и минимальный расход ресурсов процессора снова за 7-Zip в режиме LZMA, а tar.xz как черепаха неуклюжая:

На графиках гораздо лучше видна разница между разными способами архивации:

                       

На этом можно заканчивать.

Может лучшие параметры сжатия оказались не самыми быстрыми, а размер словаря в случае больших файлов пришлось увеличить до 2048 МБ, но иногда это действительно имеет смысл, даже если для распаковки потребуется два гигабайта свободной оперативной памяти...

Ну а в случае разрозненных файлов поменьше объёмом, вполне можно обойтись и размером словаря в районе 256 МБ, или даже меньше, в зависимости от архивируемых данных.

Но самое главное в сортировке данных по типам, без этого, архиватор просто не исключает дубликаты файлов (при достаточном размере словаря), которые удалять нельзя было в принципе.

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.