После почти двух лет разработки состоялся (http://savannah.gnu.org/forum/forum.php?forum_id=9049) релиз утилиты для сжатия данных gzip 1.9 (http://www.gnu.org/software/gzip/). По сравнению с прошлым выпуском внесено 53 изменения.Наиболее заметные изменения:
- Удалён код для поддержки платформ VMS и Amiga, который был неработоспособен и создавал проблемы из-за различий в требованиях к именам файлов с платформой Windows;
- В реализации команды "gzip -d -S SUFFIX fileSUFFIX" устранена проблема, мешающая использованию вместо расширения ".gz" символа в верхнем регистре, например, "gzip -d -S T fileT";
- Устранены проблемы с обработкой нулевых областей в коде конца блока при распаковке данных в формате 'pack';- В командах, реализованных через shell-скрипты, обеспечен более согласованный вывод ошибок. Например, 'gunzip --help >/dev/full' теперь приводит к выходу с кодом ошибки 1, вместо вывода кода предупреждения 2 на некоторых платформах;
- Решены проблемы, возникающие при преобразовании между системным временем в формате time_t и 32-разрядным беззнаковым форматом MTIME, используемым в gzip, при обработке моментов времени до 1970 и после
2106 на всех платформах, а также времени после 2038 года на платформах с 32-разрядным знаковым time_t. При выходе за границы допустимых значений вместо крахов и молчаливой установки максимального/минимального значения, теперь выводится предупреждение и нулевое значение времени при преобразования в MTIME или максимально близкое при преобразовании в time_t.
URL: http://savannah.gnu.org/forum/forum.php?forum_id=9049
Новость: https://www.opennet.ru/opennews/art.shtml?num=47868
Лучший компрессор по отношению скорость
/ степень сжатия
откройте для себя libdeflate
https://github.com/ebiggers/libdeflate
> откройте для себя libdeflate
>ахриваторы для 3aдpoтoв, настоящие пoсаны прессуют руками.
> ахриваторы для 3aдpoтoвGzip - компрессор, а не архиватор.
>> ахриваторы для 3aдpoтoв
> Gzip - компрессор,компрессор - это прибор для увеличения давления рабочей среды.
>... а не архиватор.
Откройте для себя https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)
pigz лучше, потому что многопоточен. 21 век, 2-ое десятилетие, а вы всё в один поток сжимаете. На ленту если, то это естественно, а на НЖД или твердотельный -- позор просто.
lbzip2 тогда уж лучше, если ядер не жалко.
А по-моему LZMA на скоростных настройках самый норм.
Сейчас лидер по отношению скорость / степень сжатия - ZSTD
Плохо сжимает.
Сжимает на таком же уровне как и zip в дефолтных режимах но при этом делая это в 1000 раз быстрее. Zstd это про очень быстую компресию и декомпресию, в не лонг тайм архивы.
> в дефолтных режимахВот именно, однако на не дефолтных все еще хуже, чем у gzip выше 1.
>> в дефолтных режимах
> Вот именно, однако на не дефолтных все еще хуже, чем у gzip выше 1.
% zstd --version && pigz --version
*** zstd command line interface 64-bits v1.3.3, by Yann Collet ***
pigz 2.4% du -b clang-check && echo this is tmpfs
50295304 clang-check
this is tmpfs% time zstd -kf -T4 clang-check && time zstd -T4 -fd clang-check.zst
clang-check : 36.34% (50295304 => 18277404 bytes, clang-check.zst)
zstd -kf -T4 clang-check 2,29s user 0,11s system 362% cpu 0,660 total
zstd -T4 -fd clang-check.zst 0,22s user 0,03s system 99% cpu 0,248 total% time zstd -8kf -T4 clang-check && time zstd -T4 -fd clang-check.zst
clang-check : 33.12% (50295304 => 16657200 bytes, clang-check.zst)
zstd -8kf -T4 clang-check 6,11s user 0,17s system 350% cpu 1,793 total
zstd -T4 -fd clang-check.zst 0,23s user 0,03s system 99% cpu 0,262 total% time pigz -1kf -p4 clang-check && du -b clang-check.gz && time pigz -fd -p4 clang-check.gz
pigz -1kf -p4 clang-check 2,56s user 0,06s system 384% cpu 0,683 total
20917773 clang-check.gz
pigz -fd -p4 clang-check.gz 0,46s user 0,06s system 127% cpu 0,406 total% time pigz -3kf -p4 clang-check && du -b clang-check.gz && time pigz -fd -p4 clang-check.gz
pigz -3kf -p4 clang-check 3,05s user 0,03s system 385% cpu 0,798 total
20084223 clang-check.gz
pigz -fd -p4 clang-check.gz 0,46s user 0,03s system 128% cpu 0,388 total% time pigz -9kf -p4 clang-check && du -b clang-check.gz && time pigz -fd -p4 clang-check.gz
pigz -9kf -p4 clang-check 11,19s user 0,09s system 388% cpu 2,905 total
19011252 clang-check.gz
pigz -fd -p4 clang-check.gz 0,42s user 0,05s system 131% cpu 0,354 total
clang-check - это попавшийся под руку "XXL"-бинарник
Можно взять более классическое:
https://github.com/dwyl/english-words/blob/master/words.txt
% repeat 10 cat words.txt >> words
% du -b words
48629660 words% time pigz -1kf -p4 words && du -b words.gz && time pigz -fd -p4 words.gz
pigz -1kf -p4 words 2,86s user 0,07s system 383% cpu 0,766 total
17584106 words.gz
pigz -fd words.gz 0,45s user 0,04s system 127% cpu 0,383 total% time pigz -3kf -p4 words && du -b words.gz && time pigz -fd -p4 words.gz
pigz -3kf -p4 words 2,66s user 0,07s system 384% cpu 0,710 total
16477338 words.gz
pigz -fd words.gz 0,43s user 0,05s system 127% cpu 0,372 total% time pigz -9kf -p4 words && du -b words.gz && time pigz -fd -p4 words.gz
pigz -9kf -p4 words 17,01s user 0,07s system 384% cpu 4,438 total
14679310 words.gz
pigz -fd words.gz 0,41s user 0,05s system 129% cpu 0,356 total% time zstd -1kf -T4 words && time zstd -T4 -fd words.zst
words : 36.30% (48629660 => 17653676 bytes, words.zst)
zstd -1kf -T4 words 1,47s user 0,12s system 363% cpu 0,439 total
zstd -T4 -fd words.zst 0,20s user 0,04s system 99% cpu 0,240 total% time zstd -8kf -T4 words && time zstd -T4 -fd words.zst
words : 29.98% (48629660 => 14579479 bytes, words.zst)
zstd -8kf -T4 words 6,29s user 0,17s system 311% cpu 2,075 total
zstd -T4 -fd words.zst 0,23s user 0,06s system 101% cpu 0,290 totalВ общем, не убедили.
ЗЫ:
Чисто для сравнения:
% time xz -9e words && du -b words.xz
xz -9e words 199,43s user 1,26s system 99% cpu 3:21,11 total
1 235 472 words.xz
% time xz -d words.xz
xz -d words.xz 0,43s user 0,09s system 99% cpu 0,521 total% time lrzip -f -z -L9 -p4 words && du -b words.lrz && time lrzip -p4 -df words.lrz
Output filename is: words.lrz
words - Compression Ratio: 68.015. Average Compression Speed: 2.000MB/s.
Total time: 00:00:23.12
lrzip -f -z -L9 -p4 words 22,73s user 0,48s system 100% cpu 23,132 total
714 986 words.lrz
Output filename is: words
Decompressing...
100% 46.38 / 46.38 MB 1:100% 2:100%
Average DeCompression Speed: 2.190MB/s
Output filename is: words: [OK] - 48629660 bytes
Total time: 00:00:21.18
lrzip -p4 -df words.lrz 20,80s user 0,34s system 99% cpu 21,193 total
А ничего что у ZSTD 22 уровня сжатия, а у gzip всего-лишь 9-ть?
> А ничего что у ZSTD 22 уровня сжатия, а у gzip всего-лишь 9-ть?Ничего. А что должно быть? Зачем "задействовать" все уровни, если с лихвой хватает первых 8? Все эти уровни вообще-то только определенный "preset", т.е. набор параметров сжималки , а не что-то мифическое.
Ну сделали в zstd аж 22, ну и бит с ними.
К тому же, на моих данных (index файлов на 20МБ, sqlite3 дамп на 60МБ, образ виртуалок на пару-тройку GB, бэкап /, по мелочи еще что-то) уровни 11+ в zstd жрут время, но не особо лучше жмут.
Каждый следующий уровень компресии увеличивает время сжатия в геометрической прогресии, и абсолютно также сводит выигрыш по обьему к минимуму.
И да, "слова" и реальные данные это разные вещи.
> И да, "слова" и реальные данные это разные вещи.Бинарник – вполне реален. Еще можно взять либу того же ФФ.
Раньше гонял еще на куче реальных файлов, но не видел смысла делать подробный прогон и выкладку, т.к. не собираюсь выкладывать соотв. файлы. Хотя…
% du -b dump.sql3
61667131 dump.sql3% time pigz -3kf -p4 dump.sql3 && du -b dump.sql3.gz && time pigz -fd -p4 dump.sql3.gz
pigz -3kf -p4 dump.sql3 2,65s user 0,12s system 389% cpu 0,711 total
16663662 dump.sql3.gz
% time pigz -9kf -p4 dump.sql3 && du -b dump.sql3.gz && time pigz -fd -p4 dump.sql3.gz
pigz -9kf -p4 dump.sql3 5,71s user 0,09s system 392% cpu 1,477 total
15431456 dump.sql3.gz% time zstd -1kf -T4 dump.sql3
dump.sql3 : 22.50% (61667131 => 13872822 bytes, dump.sql3.zst)
zstd -1kf -T4 dump.sql3 1,09s user 0,10s system 354% cpu 0,335 total
% time zstd -3kf -T4 dump.sql3
dump.sql3 : 23.58% (61667131 => 14539462 bytes, dump.sql3.zst)
% zstd -3kf -T4 dump.sql3 2,65s user 0,14s system 367% cpu 0,761 total% du -b LucidPuppy-520.vdi
732991488 LucidPuppy-520.vdi% time pigz -3kf -p4 LucidPuppy-520.vdi&& du -b LucidPuppy-520.vdi.gz
pigz -3kf -p4 LucidPuppy-520.vdi 30,08s user 0,95s system 390% cpu 7,954 total
234112973 LucidPuppy-520.vdi.gz% time pigz -9kf -p4 LucidPuppy-520.vdi&& du -b LucidPuppy-520.vdi.gz
pigz -9kf -p4 LucidPuppy-520.vdi 141,35s user 0,69s system 386% cpu 36,762 total
221347175 LucidPuppy-520.vdi% time zstd -2kf -T4 LucidPuppy-520.vdi
LucidPuppy-520.vdi : 30.28% (732991488 => 221982005 bytes, LucidPuppy-520.vdi.zst)
zstd -2kf -T4 LucidPuppy-520.vdi 9,86s user 0,81s system 371% cpu 2,874 total% time zstd -3kf -T4 LucidPuppy-520.vdi
LucidPuppy-520.vdi : 28.86% (732991488 => 211573286 bytes, LucidPuppy-520.vdi.zst)
zstd -3kf -T4 LucidPuppy-520.vdi 20,43s user 0,90s system 379% cpu 5,613 total% du -b Straustrup4th.pdf
10830547 Straustrup4th.pdf% time pigz -3kf -p4 Straustrup4th.pdf && du -b Straustrup4th.pdf.gz
pigz -3kf -p4 Straustrup4th.pdf 0,70s user 0,02s system 365% cpu 0,199 total
3192908 Straustrup4th.pdf.gz
% time pigz -9kf -p4 Straustrup4th.pdf && du -b Straustrup4th.pdf.gz
pigz -9kf -p4 Straustrup4th.pdf 1,87s user 0,02s system 383% cpu 0,494 total
2796891 Straustrup4th.pdf.gz% time zstd -1kf -T4 Straustrup4th.pdf
Straustrup4th.pdf : 28.12% (10830547 => 3045654 bytes, Straustrup4th.pdf.zst)
zstd -1kf -T4 Straustrup4th.pdf 0,22s user 0,05s system 257% cpu 0,103 total
% time zstd -3kf -T4 Straustrup4th.pdf
Straustrup4th.pdf : 26.10% (10830547 => 2827297 bytes, Straustrup4th.pdf.zst)
zstd -3kf -T4 Straustrup4th.pdf 0,31s user 0,05s system 234% cpu 0,151 total
% time zstd -6kf -T4 Straustrup4th.pdf
Straustrup4th.pdf : 24.18% (10830547 => 2619329 bytes, Straustrup4th.pdf.zst)
zstd -6kf -T4 Straustrup4th.pdf 0,54s user 0,04s system 134% cpu 0,432 total
>>> в дефолтных режимах
>> Вот именно, однако на не дефолтных все еще хуже, чем у gzip выше 1.
>
> % zstd --version && pigz --version
>Ну и кому он нахрен упёрся?
Да уж лучше, чем gzip
Скорее всего xz -0 сожмет быстрее с лучше :-)
brotli же лучше
https://certsimple.com/blog/nginx-brotli
Нет мана; ущербный синтаксис, несовместимый с остальными компрессорами; отсутствует поставка по умолчанию в дистрибутивах - если время, потраченное на решение этих проблем, доплюсовать к времени сжатия - то боюсь лучшим тут даже не пахнет. Вот когда будет нормальная реализация приложения - тогда и поговорим. Загуглить "что лучше gzip" всегда можно. Но будет ли это лучше на практике - далеко не факт.
Ты забыл про СЕКСИЗМ.
#>>Нет мана;
> Ты забыл про СЕКСИЗМ.ду*** шо ле?
> #>>Нет мана;
>> Ты забыл про СЕКСИЗМ.
> ду*** шо ле?Если бы...
https://www.theregister.co.uk/2015/10/11/googles_bro_file_fo.../
> brotli же лучше
> https://certsimple.com/blog/nginx-brotlibrotli это один из отвратительных on-the-fly компрессоров от гугла.
Бротли сильно от словаря зависит. Если характер твоих данных не подходит под выбранный словарь, то все плохо.
> brotli же лучше
> https://certsimple.com/blog/nginx-brotliСлишком медленный для сжатия на лету, а если время не важно, то LZMA все ранво круче
zstd
lz4/lz5/lizard/zstd/xz
> lz4/lz5/lizard/zstd/xz
> lz5/lizardhttps://github.com/inikep/lizard/blob/lizard/NEWS
> - LZ5 v2.0 was renamed to Lizard v1.0Ну и разница в скорости сжатия/распаковки (как и степени сжатия) cлишком уж большая, так что ниши использования lz4/lizard, zstd, xz довольно разные.
lzma
arj :)
Stari dobri arj :)
старый добрый ICE, который лУчШе
lha
Хз медленно сжимает, но намного лучше.
А вообще, включите в btrfs: chattr +c или btrfs filesystem defragment -r -v -clzo /home .
btrfs уже поддерживает zstd
Уже никто не поддерживает btrfs...
Facebook!
- gunzip --help >/dev/full
+ gunzip --help >/dev/null
Нет, именно /dev/full. Речь про код возврата при возникновении ошибки из-за отсутствия свободного места
WinRar лучше
> WinRar лучшеНо Новый Год чаще
Значительно лучше! Чем ничего.
Он был бы идеален, замени они в формате поле ISIZE (http://www.zlib.org/rfc-gzip.html) на переменной длинны или 64 битное. Но, из-за такой мелочи, формат применим ограничено, только в отдельных контейнерах, которых самих надо еще поискать адекватных.
Заменять нельзя, совместимость сломается. А вот добавить дополнительное поле могли бы.
Лучше xz -9e ничего не знаю. На скорость упаковки наплевать, пока она приемлима, главное чтобы сжатие было побольше.
> На скорость упаковки наплевать, пока она приемлима/0?
> Лучше xz -9e ничего не знаю.lrzip -z -L9
zpaq -method 5
Это из тех сжималок, которые еще более-менее присутствуют в репах и, на не сильно топовом железе, жмут хотя бы со скоростью 0.3-0.5 MB/s.Для желающих покопаться и поискать жемчужины есть еще:
http://mattmahoney.net/dc/text.htmlПравда, там часть проприетарь, часть заброшенна, часть жрет слишком уж много ресурсов.
Ну и в репах большей части сжималок естественно нема – придется собирать самому. Это не говоря о том, что вас тогда будет 3,5 пользователя (что еще более ограничивает юзкейзы).
В общем, сильно на любителя.
Универсальный архиватор тот в котором можно при сжатии задать скорость потока mb/s так как в разных ситуациях требуются разные качества архиватора
Главное, чтобы он был запущен на универсальном компьютере с универсальным процессором и универсальной памятью. А то на мерзких реальных компьютерах эти ресурсы мало что ограничены, так еще и их доступность может меняться в процессе работы универсального архиватора.
Держи: https://github.com/facebook/zstd/tree/dev/contrib/adaptive-c...
>Удалён код для поддержки платформ VMS и Amiga.Теперь не соберётся в Aros?
Сабж почти так же хорош, как и lzip (plzip) http://www.nongnu.org/lzip/
Конечно, надо отдать дедушке должное!