Компания Google открыла (http://google-opensource.blogspot.ru/2013/02/compress-data-m...реализацию нового алгоритма сжатия данных Zopfli (http://code.google.com/p/zopfli/). Представленная реализация системы сжатия совместима с библиотекой zlib (http://en.wikipedia.org/wiki/Zlib), предоставляющей поддержку контейнеров gzip и deflate, и может выступать в качестве прозрачной замены zlib. Код написан на языке Си и распространяется под лицензией Apache 2.0. Представлен только код для обеспечение сжатия, распаковка может выполняться уже существующими реализациями zlib. Zopfli также совместим на уровне битового потока с методами gzip, Zip, PNG и системами сжатия запросов HTTP.
Алгоритм (http://zopfli.googlecode.com/files/Data_compression_using_Zo... Zopfli примечателен более высокой степенью сжатия и позволяет сжимать данные в среднем на 3-8% эффективнее zlib, при этом распаковка может выполняться любыми приложениями, поддерживающими Deflate. Используемый в Zopfli метод достаточно ресурсоёмок и базируется на итерационном моделировании энтропии с использованием алгоритма поиска кратчайшего пути в графе для выбора наиболее оптимального представления сжатой последовательности из общего набора вариантов.Обратной стороной повышения коэффициента сжатия без потери совместимости является значительное повышение трудоёмкости работы алгоритма, который сжимает примерно в 100 раз медленнее zlib. Скорость распаковки архивов, созданных с использованием алгоритма Zopfli идентична другим реализациям zlib.
В качестве области использования Zopfli называются ситуации, требующие однократного сжатия данных с последующей многократной отдачей результата по сети, например, при распространении сжатого статического контента в Web. Более высокая степень сжатия позволяет уменьшить требуемое для хранения дисковое пространство, ускорить передачу данных и уменьшить задержки при загрузке web-страниц. Особенно эффект от уменьшения размера передаваемых данных может быть заметен в мобильных сетях, выражаясь в том числе в экономии потребления энергии и сокращении оплаты за принятый трафик.URL: http://google-opensource.blogspot.ru/2013/02/compress-data-m...
Новость: https://www.opennet.ru/opennews/art.shtml?num=36267
Я zlib использую исключительно там где нужна скорость, где на скорость плевать - LZMA, какой смысл делать из первого второе?
вот там и написали что "В качестве области использования Zopfli называются ситуации, требующие однократного сжатия данных с последующей многократной отдачей результата по сети"с полным сохранением совместимости
а у себя ты можешь использоваться хоть пятикратное мажоритарное кодирование, кто запрещает
> с полным сохранением совместимостиУлучшенный алгоритм сжатия, совместимый по формату потока с deflate уже давным давно давно реализован Игорем Павломым в его 7zip.
И из него внедрен в утилиты типа advancecomp и подобные по смыслу. Да, оно больше тормозит при сжатии, но жмет более качественно при сохранении совместимости формата потока с zip/gzip/deflate. Называются цифры порядка 5-10%, т.е. как раз на уровне сабжа.
А велосипедистов из гугеля поздравляем с разморозкой. Вот что бывает если вариться в своем гугловом анклаве игнорируя окружающий мир - при этом делается работа которая уже несколько лет назад как выполнена другими людьми.
Хм... после читания PDFника с результатами тестов - гугловская зоофилия таки получше по результатам теста. Тест конечно от гугли, но все-таки на более-менее общепринятом корпусе, так что я может и погорячился насчет велосипедизмов.
7zip — под лицензией LGPL, тогда как представленная библиотека — с лицензией Apache 2.0
Основное применение это веб, там вы со своим LZMA, будет как летом на базаре в лыжи обутый.
Действительно, ведь текстовые данные лучше жмёт ppmd.
> Действительно, ведь текстовые данные лучше жмёт ppmd.Это тот, у которого требования к распаковке почти идентичны требованиям при упаковке? Ну-ну =)
> Действительно, ведь текстовые данные лучше жмёт ppmd.Только вот и сервера и клиенты раком встанут если им начать пользоваться. Особенно круто будет когда вам и вашей ср@ной кош^W нетбуку сервак с 64 гигз памяти лихо скомпрессует документик для расжатия которого надо 50Гб оперативки. И будете вы неделю свопом тарахтеть...
ppmd требует мало памяти для распаковки и работает в разы быстрее zlib для текстовых данных
на фоне>сжимает примерно в 100 раз медленнее zlib
лыжи очень неплохо смотрятся.
И какой браузер умеет в Accept-Encoding: lzma?
relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=366559
А какой сервер умеет такой энкодинг отдавать?
pngcrush немного улучшится теперь?
Уже - называется optipng :)
И где там новый алгоритм, а?
http://optipng.hg.sourceforge.net/hgweb/optipng/optipng/shor...
> И где там новый алгоритм, а?Он в утилитке advancecomp, только это заслуга Игоря Павлова и его 7zip, откуда и был взят данный алгоритм. А гугл походу гуглить не умеет, раз переизобретает велик еще раз.
Чукча не читатель? В статье есть ссылка на PDF, в котором сравниваются разные реализации zlib-совместимых алгоритмов, в том числе и 7zip. И ZopFli действительно даёт лучшие результаты.
> действительно даёт лучшие результаты.Хм, действительно, он дополнительно отыгрывает пару крох на конкретно этом примере. Но там всего несколько файлов. Маловато данных для глобальных выводов, хотя в целом выглядит оптимистично.
Ох. Вы ничего не поняли - аноним пожелал "немного лучше сжимающий pngcrush", я сказал, что его уже изобрели, безо всяких гуглов :)
ОК, optipng выиграл у pngcrush (оба на максимуме настроек) 56 байт на 400К PNG файле. По сути, обе утилитки перебирают параметры PNG компрессии и потом жмут zlib с уровнем 9. Но это не то. Я спрашивал про засовывание нового алгоритма, который выдаст (условно) уровень 10 сжатия zlib.
> ОК, optipng выиграл у pngcrush (оба на максимуме настроек) 56 байт на
> 400К PNG файле. По сути, обе утилитки перебирают параметры PNG компрессииМожно попытаться до и/или после этого еще и advancecomp поиграться. Хотя идеальным был бы optipng скрещенный с advancecomp. Правда работал бы он просто неимоверно долго.
Увы, но опять мимо. advpng -z4 из пакета advancecomp жмёт один-в-один как optipng -o7, и работают оба по одному принципу - "скрещивание" бесполезно. Правда, advpng умеет менять размер словаря zlib, и, о чудо, *уменьшение* словаря с 32К (по дефолту) до 1К позволяет выиграть ещё 843 байта.
Короче, нужен z10 для zlib.
Блин, напутал. Это optipng позволяет менять размер словаря, а advpng - ниачём...
PS. все тесты под убунтой 12.04 и соотв. версии пакетов дефолтные для этого LTS.
> Увы, но опять мимо. advpng -z4 из пакета advancecomp жмёт один-в-один как
> optipng -o7, и работают оба по одному принципу - "скрещивание" бесполезно.Вообще-то основное отличие advpng - там юзается не стандартная реализация deflate из zlib и прочая, а более хорошо жмущая от Игоря Павлова. Тем не менее, advancecomp не умеет играться с префильтрами. Это чисто рекомпрессор и не более. Тогда как optipng умеет брутфорсить префильтры + параметры deflate.
> Правда, advpng умеет менять размер словаря zlib, и, о чудо, *уменьшение*
> словаря с 32К (по дефолту) до 1К позволяет выиграть ещё 843 байта.А вот это весьма и весьма зависит от конкретной картинки, между прочим. Там нет серебряных пуль. Вы только представьте себе, для разных картинок наилучшим образом подходят различные варианты параметров, по поводу чего там и реализован брутфорс. В идеале бы хорошо если бы брутфорсером проверять еще и не сожмет ли "улучшенный deflate" опосля игрища с префильтром потуже чем стандартный (что не гарантированно, но вполне возможно). Но это будет аццки долго и такого вроде никто не делал пока.
лучше на imagezero гляньте - вот что надо до ума доводить...
> лучше на imagezero гляньте - вот что надо до ума доводить...А это вообще что? И чем знаменито? А то вы так говорите как будто это все знают лучше чем гифы с пнг.
>> лучше на imagezero гляньте - вот что надо до ума доводить...
> А это вообще что?https://www.opennet.ru/opennews/art.shtml?num=32940
> И чем знаменито? А то вы так говорите
> как будто это все знают лучше чем гифы с пнг.Пока ничем не знаменито, к сожалению. А хотелось бы иметь иконки в нем. Т.к. чтение большого количества иконок (около сотни) в PNG, ощутимо подтормаживает.
3-8% эффективнее zlib. сжимает примерно в 100 раз медленнее zlibОткуда растут руки ? :-)
а голова, откуда?
> Откуда растут руки ? :-)Тут скорее вопросы к голове, ибо вы явно не в курсе как работает LZ-based и почему небольшое улучшение требует заметного падения скорости.
Hint: для повышения сжатия LZ обычно идут на некий компромисс, делая не совсем идеальный поиск совпадений, а забивая на дальнейший поиск совпадений по неким критериям ради ускорения процесса. Грубо говоря, обычно компрессор находит "достаточно хорошее" совпадение и забивает болт на дальнейший поиск. Хотя при продолжении поиска могло бы оказаться что результат можно улучшить. Ценой большей тормознутости.
Что-то такое и позволяет улучшить результат сжатия в некоторых случаях, поскрипев процессором несколько больше чем обычно. В основном это катит на сильно избыточных данных, где поиск более длинных совпадений себя оправдает. На некоторых типах данных это вообще не дает эффекта за отсутствием больших групп совпадений - это служит еще одним стимулом для того чтобы "майнлайновая" реализация не пыталась вкалывать "до победного".
>> Откуда растут руки ? :-)
> Тут скорее вопросы к голове, ибо вы явно не в курсе как
> работает LZ-based и почему небольшое улучшение требует заметного падения скорости.Каюсь :-), этого просто не знал. Thanks
> Каюсь :-), этого просто не знал. ThanksСобственно, левелы сжатия в deflate (оно же ключи gzip -1...-9) в основном указывают LZшному компрессору gzip насколько рано или поздно он должен забить на поиск совпадений.
сперва добейся
Есть набор данных, в которых значений немного, но повторяемости почти никакой.
Может кто подскажет быструю библиотечку, которая делает просто huffman, безо всякого lz.
bz2 ?
Медленно :(Хотя идея там любопытная, прочитал с интересом
> Есть набор данных, в которых значений немного, но повторяемости почти никакой.Авторы архиваторов зачастую читерят на таких данных, используя префильтр -> LZ :).
Например: 1,2,3,4,5 (нет повторяемости) -> 1,1,1,1,1(дельта) -> [1,5] (LZ сжал).А если надо именно хафмана...
1) у zlib есть стратегия с говорящим названием Z_HUFFMAN_ONLY :)
2) Можно на любом подходящем сайте поискать по слову huffman. Например, http://sourceforge.net/projects/huffman/ - неожиданно, правда? :)А так - лучше поспрашивать на специализированных ресурсах типа compression.ru. Там более предметно посоветуют, с учетом природы данных и все такое.
> в среднем на 3-8% эффективнее zlib
> который сжимает примерно в 100 раз медленнее zlib.Мило)
Зато можно сделать другой вывод: zlib настолько близка к совершенству, если без извратов лучше уже не сделаешь :)> Особенно эффект от уменьшения размера передаваемых
> данных может быть заметен в мобильных сетях, выражаясь в том числе
> в экономии потребления энергии и сокращении оплаты за принятый трафик.Если уж настолько заботятся о мобильных пользователях, то стоит подумать дальше.
webkit наиболее распространен в мобильных устройствах.
Взяли бы, да запилили поддержку xz (lzma) в webkit, весь мир бы почувствовал пользу.
xz очень хорошо сжимает и очень быстро разжимает.
По этим параметрам он обходит gzip и bzip.Понятно, что для эффекта потребовалось бы время, пока обновятся устройства, подтянутся другие браузеры и придет поддержка со стороны серверной части.
Но от xz эффект куда больше, чем 3-8%.
> xz очень хорошо сжимает и очень быстро разжимает.На встройке типа смартфонов будет плохо: xz, увы, требует некисло памяти для разжатия. Особенно для "хорошо сжатых" вещей.
Нед. LZMA памяти надо немного, но CPU - много, относительно распаковки {g}zip
>> xz очень хорошо сжимает и очень быстро разжимает.
> На встройке типа смартфонов будет плохо: xz, увы, требует некисло памяти для
> разжатия. Особенно для "хорошо сжатых" вещей."Некисло" памяти для распаковки надо если вы понапихали кучу сжатых данных ;-)
> "Некисло" памяти для распаковки надо если вы понапихали кучу сжатых данных ;-)Не обязательно эти данные целиком в памяти держать. Чисто технически достаточно объема словаря. Буфера входа/выхода можно и по ходу пьесы наполнять и скидывать.
> На встройке типа смартфонов будет плохо: xz, увы, требует некисло памяти для разжатия.По размеру словаря, не более. При том что для сжатия с тем же словарем надо многократно больше памяти. По поводу чего даже смартфон сможет нормально декомпресануть в общем случае. У LZ-based требования к сжатию и распаковке сильно несиммметричны в общем случае и распаковка обычно намного проще. Бывают даже варианты LZ где для распаковки вообще дополнительная память не требуется (LZO, UCL, ...).
>Зато можно сделать другой вывод: zlib настолько близка к совершенству, если без извратов лучше уже не сделаешь :)Если мопеду достаточно 1л.с. для разгона до 100км/ч, а McLarenF1 620л.с. до 380км/ч - это не значит, что мопед совершенен, просто на таких (200+км/ч) скоростях начинают действовать другие факторы
>xz очень хорошо сжимает и очень быстро разжимает.
>По этим параметрам он обходит gzip и bzip.LZMA где-то в 2 раза медленнее Deflate на распаковке, выводы делаем сами
это всё ерунда, ибо в вебе редко бывают очень большие запросы. На типичных размерах http пакетов xz сильно не поможетхочешь помочь мобилбьным пользователям - просто прекрати штамповать дерьмо, которое выжирает батарею за десять минут пользования. Тут я намекаю на напичканные JSом веб приложения и на клепателей "супер быстрых" JS движков, которые только дают гогнокодерам очередной повод засунуть ещё больше JSа в веб.
> http пакетовЗапросов/ответов, наверное?
И на 3G, который отжирает батарею на трафике chrome
> И на 3G, который отжирает батарею на трафике chromeOpera Mini, не?
> это всё ерунда, ибо в вебе редко бывают очень большие запросы. На
> типичных размерах http пакетов xz сильно не поможетНаверное, вы про запросы)
А это всегда можно проверить на любом посещаемом сайта.
Одну недельку посидеть без deflate сжатия.
И одну недельку посидеть с deflate сжатием.
И посмотреть счетчики (исходящий трафик, среднее время загрузки страниц в какой-нибудь метрике и т.д.).
А потом, зная, насколько xz лучше deflate, прикинуть профит от xz.
>xz очень хорошо сжимает и очень быстро разжимает.
>По этим параметрам он обходит gzip и bzip.По скорости декомпрессии нифига он не обходит gzip. Bzip2 - обходит, раз в 5.
> По скорости декомпрессии нифига он не обходит gzip.Не обходит, стадия дожатия у 7zip более тормозная чем хаффман. Но и жмет лучше. И таки при декомпрессии он развивает очень приличную скорость (как и все LZ-based).
Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.
lzo?
> lzo?Лучше: RLE, "и пусть весь мир отдохнёт" =)
>> lzo?
> Лучше: RLE, "и пусть весь мир отдохнёт" =)Тогда уж лучше совсем не сжимать :)
> Лучше: RLE,Ничем не лучше: частный случай LZ по сути. Не в пример менее эффективный на реальных данных.
>Ничем не лучше: частный случай LZ по сути.Во-первых, LZ это лишь аббревиатура от фамилий двух исследователей, алгоритм конкретно в Deflate называется LZ77 (по году публикации работы), самих вариаций на основе их работ - море
Во-вторых, RLE был задолго до LZ77, т.е. не является частным случаем последнего хотя бы потому, что он _НИГДЕ_ не оперирует счётчиками повторений
Вообщем, учи матчасть
> Во-первых, LZ это лишь аббревиатура от фамилий двух исследователей,Капитан, вы сегодня встали с левой ноги?
> Во-вторых, RLE был задолго до LZ77, т.е. не является частным случаем последнего
Вы знаете, ньютоновская механика была задолго до теории относительности. Это совершенно не мешает ей являться упрощенным частным случаем того что описывается теорией относительности. Ну вот и тут аналогично: RLE это совсем тупой вариант поиска совпадений в одной частной ситуации, а LZ - более генерализованный вариант, менее тупoрылый в допущениях. А вообще странно что мне еще какой-нибудь LZ78 или LZW не припомнили, там можно и посильнее до...ся было :)
> он _НИГДЕ_ не оперирует счётчиками повторений
Да, он вместо этого оперирует длиной совпадения. Один фиг по смыслу, только более генерально - не 1 символ копируется в вывод эн раз, а совпадение длиной эн копируется на выход. Что несколько более умный и универсальный подход, куда более эффективный на типовых данных. По сути - дальнейшее логическое развитие идеи.
> Вообщем, учи матчасть
Да я в общем то уже давно это сделал. Более того, я даже собственные RLE и LZ декомпрессоры писал, for fun и не только. Так что вы с вашим апломбом немного опоздали.
>RLE это совсем тупой вариант поиска совпадений вRLE это не вариант поиска совпадений, а способ _кодирования_ (что как бы следует из его названия), методов поиска совпадений - тонны
>RLE это совсем тупой вариант поиска совпадений в одной частной ситуации, а LZ - более генерализованный вариант
Да ну? И в каком виде в LZ77, к примеру, используется счётчик повторений (основа RLE)?
>Да, он вместо этого оперирует длиной совпадения. Один фиг по смыслу, только более генерально - не 1 символ копируется в вывод эн раз, а совпадение длиной эн копируется на выход. Что несколько более умный и универсальный подход, куда более эффективный на типовых данных. По сути - дальнейшее логическое развитие идеи.
Бла-бла-бла-демагогия, универсальный - значит подходящий для всего, а в LZ77, в который раз напомню, счётчики повторений не используются _НИГДЕ_
>Да я в общем то уже давно это сделал.
Судя по всему - слишком давно, стоит повторить
LZ4 же
> Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.или в 100 раз лучше и на 3-8% быстрее
> или в 100 раз лучше и на 3-8% быстрееА с этой проблемой борется аппаратный девайс "губозакаточная машинка".
Бабушкин залогиньтесь
> Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.Используйте LZO, LZ4, Snappy, quicklz, ... - и вы получите то что хотели. Ну может и не в сто раз, но до нескольких сотен мегабайтов в секунду на ядро они таки разгоняются.
Но это не продукция гугл... И за это не спонсируют...
> Но это не продукция гугл... И за это не спонсируют...... И не пиарят.
> Но это не продукция гугл... И за это не спонсируют...Snappy как раз гугловский.
> Но это не продукция гугл... И за это не спонсируют...А давно у гугли snappy отобрали? :) А то он в принципе достаточно конкурентоспособный, хоть и несколько горбатый в плане кода, да и вообще. Т.е. си++ на ровном месте неизвестно зачем - гугля подтвердила звание велосипедистов. Есть впрочем и вариант на чистом си от сторонних чуваков. Но это не заслуга гугли.
Но если забить на имена и уделить внимание цифрам, LZ4 обычно чутку лучше жмет при чутку более быстрой скорости, хотя все это эфемерно и от характера данных зависит. И сам код LZ4 как-то средненький весьма, велосипедиками тоже местами попахивает. И вызывает вопросы "а что если я ему на вход подам вот такой побитый поток?", например.
Наиболее солидно по коду и внятной оформленности из них выглядит, пожалуй, LZO. Оформлен как приличная либа с изрядной системой сборки, жрущей что дали (даже относительно странные и экзотичные компилеры и прочая) и ништяками полезными для кроссплатформенности. Наколенности - минимум. Код качественный и логичный, формат битстрима - достаточно понятен и не вызывает вопросов. И даже портабельные средства I/O есть, так что endianess и битность разных платформ не будет головняком пользователя либы при записи сжатых данных в файл. Протестирован на куче платформ всех мастей, битностей и endianess, чем указанные похвастать имхо не могут.
> Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.Во фантазер.. ) Ты мечтаешь в свою флэшку уместить весть интернет?
>ZopfliЗоофил, лол.
Как-то несерьезно, жмет на 3-8% в сто раз медленнее.
Я так понял предлагают им в вебе статику и данные аля JSON паковать? Первое еще ладно, но каждый запрос со стократной нагрузкой жать - это только гугле себе может позволить.
> Я так понял предлагают им в вебе статику и данные аля JSON паковать?Да это гугл долго отпускал ручник, advancecomp с улучшенным deflate из 7zip-а для перепаковки подобного барахла в репах у дистров уже несколько лет как есть. И только до гугля как до жирафов. Ну и NIH, куда же без него.
>> Я так понял предлагают им в вебе статику и данные аля JSON паковать?
> Да это гугл долго отпускал ручник, advancecomp с улучшенным deflate из 7zip-а
> для перепаковки подобного барахла в репах у дистров уже несколько лет
> как есть. И только до гугля как до жирафов. Ну и
> NIH, куда же без него.Вы посмелее возражайте - может выйдете из ГИПНОЗА! )))
> Вы посмелее возражайте - может выйдете из ГИПНОЗА! )))Да нет там никакого гипноза - велосипедят в гугле по черному. Snappy уже навелосипедили. При том что он в принципе сопоставим с LZO и обычно немного проигрывает и по скорости и по степени сжатия LZ4. И зачем-то си++ за уши притянут, хотя от си++ ничего и не используется почти. Зато область применения заметно сужает - севая либа более широко применима. Например в ядре, etc. О, кстати...
>> Я так понял предлагают им в вебе статику и данные аля JSON паковать?
> Да это гугл долго отпускал ручник, advancecomp с улучшенным deflate из 7zip-а
> для перепаковки подобного барахла в репах у дистров уже несколько лет
> как есть. И только до гугля как до жирафов. Ну и
> NIH, куда же без него.Гугл переложил проблему серверов на пользователя!
>>Zopfli
> Зоофил, лол.
> Как-то несерьезно, жмет на 3-8% в сто раз медленнее.
> Я так понял предлагают им в вебе статику и данные аля JSON
> паковать? Первое еще ладно, но каждый запрос со стократной нагрузкой жать
> - это только гугле себе может позволить.Так и запросов на контент в сто раз меньше. Пока клиент пережует... )))
>Обратной стороной повышения коэффициента сжатия без потери совместимости >является значительное повышение трудоёмкости работы алгоритма, который сжимает >примерно в 100 раз медленнее zlib.Может быть ключевым моментом фразы является - " без потери совместимости"?...
Гугл открыл алгоритм, которому мешают "путы прошлой совместимости"?
> Может быть ключевым моментом фразы является - " без потери совместимости"?...
> Гугл открыл алгоритм, которому мешают "путы прошлой совместимости"?Да.
Но.
Они могут протолкнуть и lzma/xz в качестве ещё одного способа сжатия в браузеры и серверы.
Если уж такую штуку, как spdy проталкивают.
https://aur.archlinux.org/packages/zopfli-git/
> https://aur.archlinux.org/packages/zopfli-git/
msg "Connecting to the midori git repository..."И вот всё у них так, а потом спрашивают, зачем rpm такие сложные макросы.
Создавал на основе другого PKGBUILD, уже все исправленно...
> Создавал на основе другого PKGBUILDДа это понятно, просто с макросами могло обойтись даже без помарки :)
> уже все исправлено...
Затем и сообщал.
Для кэш-серверов это будет хорошей находкой.
Откуда информация про "медленнее в 100 раз"?
С сайта производителя. Вчера только щупал эти zopfli, какой-то экстраординарной тормознутости не заметил. С другой стороны, я не все опции пробовал.
> С сайта производителя. Вчера только щупал эти zopfli, какой-то экстраординарной тормознутости
> не заметил. С другой стороны, я не все опции пробовал.Можете скинуть цитату? Я её почему-то упорно не нахожу.
"жмет на 3-8% " это только мне показалось несерьезным...а для скорости юзайте Parallel gzip = pigz (http://zlib.net/pigz/)
вроде есть в репозиториях
> "жмет на 3-8% " это только мне показалось несерьезным..._плотнее_
> а для скорости юзайте Parallel gzip = pigz
У него компрессия довольно заметно падает на интересных количествах ядер, к сожалению.
>> а для скорости юзайте Parallel gzip = pigz
> У него компрессия довольно заметно падает на интересных количествах ядер, к сожалению.Нет, не очень.
А чем это лучше того, что делает 7zip ?7za a -tgzip -mx9 -mpass=15 -mfb=257 -ba -bd compressed.gz raw
дает файл меньшего размера, чем gzip -9 при этом формат тот же.
Тест на файле jquery-1.9.1.js
исходный размер - 268381 байт.gzip -9: 79522 байт, 0.064 sec
7zip: 76067 байт, 1.605 sec