Какой архиватор сейчас самый быстрый?

lzo

Библиотека для сжатия данных от Google

винрар же

два кусочка рафинада этому господину.

>Какой архиватор сейчас самый быстрый?

самый быстрый

lzo не самый быстрый? а squashfs? короче хз, кастую сравнительные тесты с фороникса :)

в некоторых случаях : pbzip2
http://compression.ca/pbzip2/

Snappy/Yappy.

Скорость упаковки важна, скорость распаковки важнее. Степень сжатия не особо важна.

[troll] tar [/troll] :)

+ http://www.compression.ru/arctest/act/act-calg.htm

+ минитест (1000M .img, 2x core):

$ time lzma -1 Linux.img 
real	0m29.077s
user	0m27.831s
sys	0m1.191s

$ time lzma -d Linux.img.lzma 
real	0m3.964s
user	0m3.945s
sys	0m0.004s

$ time pbzip2 -1 Linux.img 
real	0m15.728s
user	0m26.561s
sys	0m2.087s

$ time pbunzip2 Linux.img.bz2 
real	0m24.031s
user	0m6.023s
sys	0m1.549s

>Поэтому я счёл формат ZIP целесообразнее 7Z.

так это ж контейнеры, все едино. Я недавно дампы баз сжимал методом LZMA и засовывал в zip. Скорость сжатия на третьей степени намного выше обычного deflate (тот самый, который в обычном зипе со времен pkzip), при этом сжимается лучше. Скорость распаковки не измерял, мне было важнее, чтоб открывалось даже голой вендой :)

А так можешь взять 7z в руки да проверить на одном своем файле. Контейнеров и методов сжатия не так и много.

>Май, 2002

Некрофилия в треде!

pbzip2

pigz (parallel gzip)

tar

Степень сжатия не особо важна.

Тем более. А за сжатием вообще обращаться к компрессорам.

exdupe maximumcompression fs compression

> lzo

В пакете отсутствуют исполнимые файлы. Использовать пакет lzop?

> Библиотека для сжатия данных от Google

Snappy? Спасибо, попробую, тем более ебилд уже есть.

> винрар

Чем он лучше нативного консольного rar-а? А заодно и виндового консольного?

> http://www.compression.ru/arctest/act/act-calg.htm

2002 год. Поновее нету?

> Snappy

Спасибо, смотрю...

/Yappy.

А это что?

> минитест

Спасибо. Надеюсь, Linux.img — несжатый? :)

Насколько я помню, LZMA — 1-поточный. Даже если его научились распараллеливать, в программе lzma была старая версия алгоритма.

То есть 1-поточный LZMA сжимает на проценты медленнее, чем 2-поточный bzip2. А распаковывает вдвое быстрее.

Насколько я знаю deflate (в zip/gzip) — ещё быстрее LZMA.

То есть про pbzip2 можно не вспоминать.

> так это ж контейнеры, все едино

Я имел в виду методы, используемые в этих контейнерах по умолчанию. LZMA для 7z и deflate для zip.

Скорость сжатия на третьей степени

Это как? «7z -mx=3» ?

намного выше обычного deflate (тот самый, который в обычном зипе со времен pkzip), при этом сжимается лучше.

Попробую, спасибо. Но для «7z -tzip -mx=1», вроде получилось медленне, чем с «7z -tzip -mx=1» при несущественном выигрыше в сжатии.

Скорость распаковки не измерял, мне было важнее, чтоб открывалось даже голой вендой :)

Достаточно взять версию 7-zip не ниже :)

А так можешь взять 7z в руки да проверить на одном своем файле.

С -mx=1 сжимается полчаса.

> pigz (parallel gzip)

Спасибо. И большой выигрыш здесь даёт параллелизм? Будет ли прирост на 4-ядерном процессоре по сравнению с 2-ядерным?

> tar ... А за сжатием вообще обращаться к компрессорам.

Где взять патчи для tar-а для поддержки компрессоров pigz, lzop и snappy? ОС с кривой реализацией пайпов, tar чтототам | gzip работает через раз.

> http://exdupe.com/

Нет 32-битной версии.

К тому же закрытый. И ни одного стороннего отзыва в интернете не нашёл.

И возникают подозрения: зачем архиватору доступ к IPX, AppleTalk и /proc/net ?

http://maximumcompression.com/data/summary_mf4.php

Автору нравится FreeARC :) Snappy в списке нет. Но в остальном хорошая таблица.

http://extrememoderate.wordpress.com/2011/08/20/synthetic-test-of-filesystem-...

Довольно специфическая задача. Но хотя бы показывает соотношение Snappy-LZO. Спасибо.

Та же фигня, только от Яндекса.

>параллелизм

Попробуй lrzip от Коливаса. Он даже PAQ параллелит.

> lrzip

Спасибо, посмотрю и его заодно.

Хотя в http://ck.kolivas.org/apps/lrzip/README ничего нет о параллелизме. И на файлах больше 10 гигабайт 32-битная версия проигрывает стандартным реализациям LZMA.

> Та же фигня, только от Яндекса.

Snappy с их патчами? Ссылку можно? А то в поиске одни чихуахуа.

Какой архиватор сейчас самый быстрый?

tar?

Я по его блогу сужу - он там подробности постоянно пишет.

гоню, гоню. Но компрессор есть - http://blog.gamedeff.com/?p=371

> tar?

Есть сильные подозрения, что что-нибудь быстро сжимающее и разжимающее (на основе LZO?) обработает большой объём хорошо сжимаемых данных быстрее. Будет меньше работы с диском.

обращаю внимание уважаемого:

скорость распаковки важнее

так что быстрее не будет

> http://blog.gamedeff.com/?p=371

:)

Быстро. Но автор пишет, что на больших объёмах будет проигрывать Snappy.

Спасибо.

>>скорость распаковки важнее

так что быстрее не будет

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

Плюсую tar :). А потом сверху любой компрессор.

tar cf -O /dev/null??

> tar cf -O /dev/null

Попробуй это запустить :) Заодно узнаешь размер /dev/null в архиве.

да, lzop.

> Плюсую tar :). А потом сверху любой компрессор.

Который компрессор?

> да, lzop.

Спасибо.

xz, например.

ну я подразумевал в качестве архиватора /dev/null. может выразился немного неправильно)

> xz, например.

Никаких преимуществ перед LZMA из свежего 7-zip. Кроме сохранения атрибутов, которые в данном случае не играют роли, т.к. по умолчанию. И долго работает.

2002 год. Поновее нету?

алгоритмы обычно не меняются, даже если со временем изменились цифры - общее соотношение осталось прежним

вот, к примеру, я еще с конца 90х помню что rar сжимает текст лучше чем zip
и я даже проверять не буду, уверен за 10 лет ничего не изменилось

Спасибо. Надеюсь, Linux.img — несжатый? :)

это образ какой-то вм, qemu чтоль
зх как там с сжатием, но уверен там много нулей ;)

> >> 2002 год. Поновее нету?

алгоритмы обычно не меняются,

Неверно.

Кроме того, конкретные реализации важнее.

даже если со временем изменились цифры - общее соотношение осталось прежним

Опять неверно.

вот, к примеру, я еще с конца 90х помню что rar сжимает текст лучше чем zip

и я даже проверять не буду, уверен за 10 лет ничего не изменилось

Учитывая, что zip не развивается с середины 1990-х, неудивительно. А вот про реализацию deflate в 7-zip я бы не был не столь уверен :)

Ещё контрпример: 15 лет назад rar уступал ha. Сейчас превосходит.

Linux.img

это образ какой-то вм,

Так и запишем, с ядром линукса anTaRes не знаком :)

Так и запишем, с ядром линукса anTaRes не знаком :)

ядро тут не причем , это образ виртуалки
а что там внутри - хз, возможно она вообще пустая :)
но Вам же образы и сжимать, ткчто они тоже не всегда на 100% заполнены будут
и даже со степенью сжатия «1» можно будет раз в 5-10 ужать

вобшшем как определитесь - обнародуйте свое решение ;) интересно будет узнать что выбрали и почему

>Это как? «7z -mx=3» ?
угу

Но для «7z -tzip -mx=1», вроде получилось медленне, чем с «7z -tzip -mx=1» при несущественном выигрыше в сжатии.

не понял, что с чем сравниваешь :) Deflate тормоз изначально, при этом ЕМНИП работает только в один поток

Достаточно взять версию 7-zip не ниже :)

неа, в том и фишка, что открывается без сторонних приблуд

С -mx=1 сжимается полчаса.

так отрежь от него кусок небольшой для теста

xz сжимает лучше всяких bzip'ов и gzip'ов.