| 1.1, Аноним (1), 16:20, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +15 +/– |
 Я zlib использую исключительно там где нужна скорость, где на скорость плевать - LZMA, какой смысл делать из первого второе?
| | |
| |
| 2.2, хрюкотающий зелюк (?), 16:23, 01/03/2013 [^] [^^] [^^^] [ответить]
| +6 +/– | |
вот там и написали что "В качестве области использования Zopfli называются ситуации, требующие однократного сжатия данных с последующей многократной отдачей результата по сети"
с полным сохранением совместимости
а у себя ты можешь использоваться хоть пятикратное мажоритарное кодирование, кто запрещает
| | |
| |
| 3.27, Аноним (-), 20:34, 01/03/2013 [^] [^^] [^^^] [ответить]
| +9 +/– | |
> с полным сохранением совместимости
Улучшенный алгоритм сжатия, совместимый по формату потока с deflate уже давным давно давно реализован Игорем Павломым в его 7zip.
И из него внедрен в утилиты типа advancecomp и подобные по смыслу. Да, оно больше тормозит при сжатии, но жмет более качественно при сохранении совместимости формата потока с zip/gzip/deflate. Называются цифры порядка 5-10%, т.е. как раз на уровне сабжа.
А велосипедистов из гугеля поздравляем с разморозкой. Вот что бывает если вариться в своем гугловом анклаве игнорируя окружающий мир - при этом делается работа которая уже несколько лет назад как выполнена другими людьми.
| | |
| |
| 4.45, Аноним (-), 22:07, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Хм... после читания PDFника с результатами тестов - гугловская зоофилия таки получше по результатам теста. Тест конечно от гугли, но все-таки на более-менее общепринятом корпусе, так что я может и погорячился насчет велосипедизмов.
| | |
| 4.83, Аноним (-), 20:55, 02/03/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
7zip — под лицензией LGPL, тогда как представленная библиотека — с лицензией Apache 2.0
| | |
|
|
| 2.4, Vaso Petrovich (?), 16:44, 01/03/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
Основное применение это веб, там вы со своим LZMA, будет как летом на базаре в лыжи обутый.
| | |
| |
| |
| 4.22, z (??), 19:47, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Действительно, ведь текстовые данные лучше жмёт ppmd.
Это тот, у которого требования к распаковке почти идентичны требованиям при упаковке? Ну-ну =)
| | |
| 4.28, Аноним (-), 20:35, 01/03/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Действительно, ведь текстовые данные лучше жмёт ppmd.
Только вот и сервера и клиенты раком встанут если им начать пользоваться. Особенно круто будет когда вам и вашей ср@ной кош^W нетбуку сервак с 64 гигз памяти лихо скомпрессует документик для расжатия которого надо 50Гб оперативки. И будете вы неделю свопом тарахтеть...
| | |
| |
| 5.85, Марк Шатлворт (?), 23:22, 02/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
ppmd требует мало памяти для распаковки и работает в разы быстрее zlib для текстовых данных
| | |
|
|
| 3.75, koloboid (ok), 11:20, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
 на фоне
>сжимает примерно в 100 раз медленнее zlib
лыжи очень неплохо смотрятся.
| | |
|
|
| |
| |
| |
| 4.30, Аноним (-), 20:36, 01/03/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> И где там новый алгоритм, а?
Он в утилитке advancecomp, только это заслуга Игоря Павлова и его 7zip, откуда и был взят данный алгоритм. А гугл походу гуглить не умеет, раз переизобретает велик еще раз.
| | |
| |
| 5.41, Lockal (ok), 21:26, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Чукча не читатель? В статье есть ссылка на PDF, в котором сравниваются разные реализации zlib-совместимых алгоритмов, в том числе и 7zip. И ZopFli действительно даёт лучшие результаты.
| | |
| |
| 6.43, Аноним (-), 22:02, 01/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> действительно даёт лучшие результаты.
Хм, действительно, он дополнительно отыгрывает пару крох на конкретно этом примере. Но там всего несколько файлов. Маловато данных для глобальных выводов, хотя в целом выглядит оптимистично.
| | |
|
|
| 4.57, Stax (ok), 22:53, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
 Ох. Вы ничего не поняли - аноним пожелал "немного лучше сжимающий pngcrush", я сказал, что его уже изобрели, безо всяких гуглов :)
| | |
| |
| 5.65, Аноним (-), 23:51, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
ОК, optipng выиграл у pngcrush (оба на максимуме настроек) 56 байт на 400К PNG файле. По сути, обе утилитки перебирают параметры PNG компрессии и потом жмут zlib с уровнем 9. Но это не то. Я спрашивал про засовывание нового алгоритма, который выдаст (условно) уровень 10 сжатия zlib.
| | |
| |
| 6.69, Аноним (-), 01:42, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
> ОК, optipng выиграл у pngcrush (оба на максимуме настроек) 56 байт на
> 400К PNG файле. По сути, обе утилитки перебирают параметры PNG компрессии
Можно попытаться до и/или после этого еще и advancecomp поиграться. Хотя идеальным был бы optipng скрещенный с advancecomp. Правда работал бы он просто неимоверно долго.
| | |
| |
| 7.77, Аноним (-), 11:51, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Увы, но опять мимо. advpng -z4 из пакета advancecomp жмёт один-в-один как optipng -o7, и работают оба по одному принципу - "скрещивание" бесполезно. Правда, advpng умеет менять размер словаря zlib, и, о чудо, *уменьшение* словаря с 32К (по дефолту) до 1К позволяет выиграть ещё 843 байта.
Короче, нужен z10 для zlib.
| | |
| |
| 8.90, Аноним (-), 02:50, 03/03/2013 [^] [^^] [^^^] [ответить] | +/– | Вообще-то основное отличие advpng - там юзается не стандартная реализация deflat... большой текст свёрнут, показать | | |
|
|
| |
| 7.91, Аноним (-), 02:56, 03/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> лучше на imagezero гляньте - вот что надо до ума доводить...
А это вообще что? И чем знаменито? А то вы так говорите как будто это все знают лучше чем гифы с пнг.
| | |
|
|
|
|
|
|
| 1.8, SergMarkov (ok), 17:19, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –9 +/– |
 3-8% эффективнее zlib. сжимает примерно в 100 раз медленнее zlib
Откуда растут руки ? :-)
| | |
| |
| 2.31, Аноним (-), 20:41, 01/03/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Тут скорее вопросы к голове, ибо вы явно не в курсе как работает LZ-based и поче... большой текст свёрнут, показать | | |
| |
| 3.66, SergMarkov (ok), 00:45, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Откуда растут руки ? :-)
> Тут скорее вопросы к голове, ибо вы явно не в курсе как
> работает LZ-based и почему небольшое улучшение требует заметного падения скорости.
Каюсь :-), этого просто не знал. Thanks
| | |
| |
| 4.89, Аноним (-), 02:43, 03/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Каюсь :-), этого просто не знал. Thanks
Собственно, левелы сжатия в deflate (оно же ключи gzip -1...-9) в основном указывают LZшному компрессору gzip насколько рано или поздно он должен забить на поиск совпадений.
| | |
|
|
|
| 1.9, Аноним (-), 17:46, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Есть набор данных, в которых значений немного, но повторяемости почти никакой.
Может кто подскажет быструю библиотечку, которая делает просто huffman, безо всякого lz.
| | |
| |
| 2.35, Аноним (-), 21:02, 01/03/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Есть набор данных, в которых значений немного, но повторяемости почти никакой.
Авторы архиваторов зачастую читерят на таких данных, используя префильтр -> 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. Там более предметно посоветуют, с учетом природы данных и все такое.
| | |
|
| 1.11, XoRe (ok), 18:40, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 > в среднем на 3-8% эффективнее zlib
> который сжимает примерно в 100 раз медленнее zlib.
Мило)
Зато можно сделать другой вывод: zlib настолько близка к совершенству, если без извратов лучше уже не сделаешь :)
> Особенно эффект от уменьшения размера передаваемых
> данных может быть заметен в мобильных сетях, выражаясь в том числе
> в экономии потребления энергии и сокращении оплаты за принятый трафик.
Если уж настолько заботятся о мобильных пользователях, то стоит подумать дальше.
webkit наиболее распространен в мобильных устройствах.
Взяли бы, да запилили поддержку xz (lzma) в webkit, весь мир бы почувствовал пользу.
xz очень хорошо сжимает и очень быстро разжимает.
По этим параметрам он обходит gzip и bzip.
Понятно, что для эффекта потребовалось бы время, пока обновятся устройства, подтянутся другие браузеры и придет поддержка со стороны серверной части.
Но от xz эффект куда больше, чем 3-8%.
| | |
| |
| 2.13, Stax (ok), 18:51, 01/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> xz очень хорошо сжимает и очень быстро разжимает.
На встройке типа смартфонов будет плохо: xz, увы, требует некисло памяти для разжатия. Особенно для "хорошо сжатых" вещей.
| | |
| |
| 3.17, Аноним (-), 19:26, 01/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нед. LZMA памяти надо немного, но CPU - много, относительно распаковки {g}zip
| | |
| 3.19, ip1981 (ok), 19:30, 01/03/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
 >> xz очень хорошо сжимает и очень быстро разжимает.
> На встройке типа смартфонов будет плохо: xz, увы, требует некисло памяти для
> разжатия. Особенно для "хорошо сжатых" вещей.
"Некисло" памяти для распаковки надо если вы понапихали кучу сжатых данных ;-)
| | |
| |
| 4.88, Аноним (-), 02:38, 03/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> "Некисло" памяти для распаковки надо если вы понапихали кучу сжатых данных ;-)
Не обязательно эти данные целиком в памяти держать. Чисто технически достаточно объема словаря. Буфера входа/выхода можно и по ходу пьесы наполнять и скидывать.
| | |
|
| 3.36, Аноним (-), 21:07, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> На встройке типа смартфонов будет плохо: xz, увы, требует некисло памяти для разжатия.
По размеру словаря, не более. При том что для сжатия с тем же словарем надо многократно больше памяти. По поводу чего даже смартфон сможет нормально декомпресануть в общем случае. У LZ-based требования к сжатию и распаковке сильно несиммметричны в общем случае и распаковка обычно намного проще. Бывают даже варианты LZ где для распаковки вообще дополнительная память не требуется (LZO, UCL, ...).
| | |
|
| 2.20, z (??), 19:43, 01/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Зато можно сделать другой вывод: zlib настолько близка к совершенству, если без извратов лучше уже не сделаешь :)
Если мопеду достаточно 1л.с. для разгона до 100км/ч, а McLarenF1 620л.с. до 380км/ч - это не значит, что мопед совершенен, просто на таких (200+км/ч) скоростях начинают действовать другие факторы
>xz очень хорошо сжимает и очень быстро разжимает.
>По этим параметрам он обходит gzip и bzip.
LZMA где-то в 2 раза медленнее Deflate на распаковке, выводы делаем сами
| | |
| 2.32, all_glory_to_the_hypnotoad (ok), 20:42, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
 это всё ерунда, ибо в вебе редко бывают очень большие запросы. На типичных размерах http пакетов xz сильно не поможет
хочешь помочь мобилбьным пользователям - просто прекрати штамповать дерьмо, которое выжирает батарею за десять минут пользования. Тут я намекаю на напичканные JSом веб приложения и на клепателей "супер быстрых" JS движков, которые только дают гогнокодерам очередной повод засунуть ещё больше JSа в веб.
| | |
| |
| |
| 4.97, Аноним (-), 21:22, 03/03/2013 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> И на 3G, который отжирает батарею на трафике chrome
Opera Mini, не?
| | |
|
| 3.74, XoRe (ok), 11:19, 02/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> это всё ерунда, ибо в вебе редко бывают очень большие запросы. На
> типичных размерах http пакетов xz сильно не поможет
Наверное, вы про запросы)
А это всегда можно проверить на любом посещаемом сайта.
Одну недельку посидеть без deflate сжатия.
И одну недельку посидеть с deflate сжатием.
И посмотреть счетчики (исходящий трафик, среднее время загрузки страниц в какой-нибудь метрике и т.д.).
А потом, зная, насколько xz лучше deflate, прикинуть профит от xz.
| | |
|
| 2.56, Led (ok), 22:47, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
 >xz очень хорошо сжимает и очень быстро разжимает.
>По этим параметрам он обходит gzip и bzip.
По скорости декомпрессии нифига он не обходит gzip. Bzip2 - обходит, раз в 5.
| | |
| |
| 3.70, Аноним (-), 01:45, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> По скорости декомпрессии нифига он не обходит gzip.
Не обходит, стадия дожатия у 7zip более тормозная чем хаффман. Но и жмет лучше. И таки при декомпрессии он развивает очень приличную скорость (как и все LZ-based).
| | |
|
|
| |
| |
| 3.21, z (??), 19:45, 01/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> lzo?
Лучше: RLE, "и пусть весь мир отдохнёт" =)
| | |
| |
| 4.26, Аноним (-), 20:06, 01/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> lzo?
> Лучше: RLE, "и пусть весь мир отдохнёт" =)
Тогда уж лучше совсем не сжимать :)
| | |
| 4.44, Аноним (-), 22:03, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Лучше: RLE,
Ничем не лучше: частный случай LZ по сути. Не в пример менее эффективный на реальных данных.
| | |
| |
| 5.79, z (??), 12:32, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>Ничем не лучше: частный случай LZ по сути.
Во-первых, LZ это лишь аббревиатура от фамилий двух исследователей, алгоритм конкретно в Deflate называется LZ77 (по году публикации работы), самих вариаций на основе их работ - море
Во-вторых, RLE был задолго до LZ77, т.е. не является частным случаем последнего хотя бы потому, что он _НИГДЕ_ не оперирует счётчиками повторений
Вообщем, учи матчасть
| | |
| |
| 6.87, Аноним (-), 02:34, 03/03/2013 [^] [^^] [^^^] [ответить] | +/– | Капитан, вы сегодня встали с левой ноги Вы знаете, ньютоновская механика была з... большой текст свёрнут, показать | | |
| |
| 7.96, z (??), 19:02, 03/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
>RLE это совсем тупой вариант поиска совпадений в
RLE это не вариант поиска совпадений, а способ _кодирования_ (что как бы следует из его названия), методов поиска совпадений - тонны
>RLE это совсем тупой вариант поиска совпадений в одной частной ситуации, а LZ - более генерализованный вариант
Да ну? И в каком виде в LZ77, к примеру, используется счётчик повторений (основа RLE)?
>Да, он вместо этого оперирует длиной совпадения. Один фиг по смыслу, только более генерально - не 1 символ копируется в вывод эн раз, а совпадение длиной эн копируется на выход. Что несколько более умный и универсальный подход, куда более эффективный на типовых данных. По сути - дальнейшее логическое развитие идеи.
Бла-бла-бла-демагогия, универсальный - значит подходящий для всего, а в LZ77, в который раз напомню, счётчики повторений не используются _НИГДЕ_
>Да я в общем то уже давно это сделал.
Судя по всему - слишком давно, стоит повторить
| | |
|
|
|
|
|
| 2.24, Аноним (-), 19:56, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.
или в 100 раз лучше и на 3-8% быстрее
| | |
| |
| 3.39, Аноним (-), 21:10, 01/03/2013 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> или в 100 раз лучше и на 3-8% быстрее
А с этой проблемой борется аппаратный девайс "губозакаточная машинка".
| | |
|
| 2.38, Аноним (-), 21:09, 01/03/2013 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.
Используйте LZO, LZ4, Snappy, quicklz, ... - и вы получите то что хотели. Ну может и не в сто раз, но до нескольких сотен мегабайтов в секунду на ядро они таки разгоняются.
| | |
| |
| |
| 4.63, Аноним (-), 23:21, 01/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Но это не продукция гугл... И за это не спонсируют...
... И не пиарят.
| | |
| 4.67, Sokoloff (?), 00:52, 02/03/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Но это не продукция гугл... И за это не спонсируют...
Snappy как раз гугловский.
| | |
| 4.71, Аноним (-), 02:00, 02/03/2013 [^] [^^] [^^^] [ответить] | +/– | А давно у гугли snappy отобрали А то он в принципе достаточно конкурентоспос... большой текст свёрнут, показать | | |
|
|
| 2.50, Аноним (-), 22:28, 01/03/2013 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.
Во фантазер.. ) Ты мечтаешь в свою флэшку уместить весть интернет?
| | |
|
| 1.37, Okarin (ok), 21:07, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 >Zopfli
Зоофил, лол.
Как-то несерьезно, жмет на 3-8% в сто раз медленнее.
Я так понял предлагают им в вебе статику и данные аля JSON паковать? Первое еще ладно, но каждый запрос со стократной нагрузкой жать - это только гугле себе может позволить.
| | |
| |
| 2.40, Аноним (-), 21:11, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Я так понял предлагают им в вебе статику и данные аля JSON паковать?
Да это гугл долго отпускал ручник, advancecomp с улучшенным deflate из 7zip-а для перепаковки подобного барахла в репах у дистров уже несколько лет как есть. И только до гугля как до жирафов. Ну и NIH, куда же без него.
| | |
| |
| 3.52, Аноним (-), 22:31, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Я так понял предлагают им в вебе статику и данные аля JSON паковать?
> Да это гугл долго отпускал ручник, advancecomp с улучшенным deflate из 7zip-а
> для перепаковки подобного барахла в репах у дистров уже несколько лет
> как есть. И только до гугля как до жирафов. Ну и
> NIH, куда же без него.
Вы посмелее возражайте - может выйдете из ГИПНОЗА! )))
| | |
| |
| 4.92, Аноним (-), 06:34, 03/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Вы посмелее возражайте - может выйдете из ГИПНОЗА! )))
Да нет там никакого гипноза - велосипедят в гугле по черному. Snappy уже навелосипедили. При том что он в принципе сопоставим с LZO и обычно немного проигрывает и по скорости и по степени сжатия LZ4. И зачем-то си++ за уши притянут, хотя от си++ ничего и не используется почти. Зато область применения заметно сужает - севая либа более широко применима. Например в ядре, etc. О, кстати...
| | |
|
| 3.54, Аноним (-), 22:32, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Я так понял предлагают им в вебе статику и данные аля JSON паковать?
> Да это гугл долго отпускал ручник, advancecomp с улучшенным deflate из 7zip-а
> для перепаковки подобного барахла в репах у дистров уже несколько лет
> как есть. И только до гугля как до жирафов. Ну и
> NIH, куда же без него.
Гугл переложил проблему серверов на пользователя!
| | |
|
| 2.51, Аноним (-), 22:30, 01/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>Zopfli
> Зоофил, лол.
> Как-то несерьезно, жмет на 3-8% в сто раз медленнее.
> Я так понял предлагают им в вебе статику и данные аля JSON
> паковать? Первое еще ладно, но каждый запрос со стократной нагрузкой жать
> - это только гугле себе может позволить.
Так и запросов на контент в сто раз меньше. Пока клиент пережует... )))
| | |
|
| 1.55, Аноним (-), 22:41, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Обратной стороной повышения коэффициента сжатия без потери совместимости >является значительное повышение трудоёмкости работы алгоритма, который сжимает >примерно в 100 раз медленнее zlib.
Может быть ключевым моментом фразы является - " без потери совместимости"?...
Гугл открыл алгоритм, которому мешают "путы прошлой совместимости"?
| | |
| |
| 2.76, XoRe (ok), 11:23, 02/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Может быть ключевым моментом фразы является - " без потери совместимости"?...
> Гугл открыл алгоритм, которому мешают "путы прошлой совместимости"?
Да.
Но.
Они могут протолкнуть и lzma/xz в качестве ещё одного способа сжатия в браузеры и серверы.
Если уж такую штуку, как spdy проталкивают.
| | |
|
| |
| |
| |
| 4.86, Michael Shigorin (ok), 01:40, 03/03/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Создавал на основе другого PKGBUILD
Да это понятно, просто с макросами могло обойтись даже без помарки :)
> уже все исправлено...
Затем и сообщал.
| | |
|
|
|
| |
| 2.102, dq0s4y71 (??), 18:13, 06/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
С сайта производителя. Вчера только щупал эти zopfli, какой-то экстраординарной тормознутости не заметил. С другой стороны, я не все опции пробовал.
| | |
| |
| 3.103, cijic (ok), 19:12, 06/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
 > С сайта производителя. Вчера только щупал эти zopfli, какой-то экстраординарной тормознутости
> не заметил. С другой стороны, я не все опции пробовал.
Можете скинуть цитату? Я её почему-то упорно не нахожу.
| | |
|
|
| |
| 2.99, Michael Shigorin (ok), 15:04, 04/03/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> "жмет на 3-8% " это только мне показалось несерьезным...
_плотнее_
> а для скорости юзайте Parallel gzip = pigz
У него компрессия довольно заметно падает на интересных количествах ядер, к сожалению.
| | |
| |
| 3.100, Led (ok), 15:49, 04/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> а для скорости юзайте Parallel gzip = pigz
> У него компрессия довольно заметно падает на интересных количествах ядер, к сожалению.
Нет, не очень.
| | |
|
|
| 1.104, Anton (??), 11:35, 12/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
А чем это лучше того, что делает 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
| | |
|
