The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Компания Google представила совместимый с zlib алгоритм сжатия Zopfli

01.03.2013 15:49

Компания Google открыла реализацию нового алгоритма сжатия данных Zopfli. Представленная реализация системы сжатия совместима с библиотекой zlib, предоставляющей поддержку контейнеров gzip и deflate, и может выступать в качестве прозрачной замены zlib. Код написан на языке Си и распространяется под лицензией Apache 2.0. Представлен только код для обеспечения сжатия, распаковка может выполняться уже существующими реализациями zlib. Zopfli также совместим на уровне битового потока с методами gzip, Zip, PNG и системами сжатия запросов HTTP.

Алгоритм Zopfli примечателен более высокой степенью сжатия и позволяет сжимать данные в среднем на 3-8% эффективнее zlib, при этом распаковка может выполняться любыми приложениями, поддерживающими Deflate. Используемый в Zopfli метод достаточно ресурсоёмок и базируется на итерационном моделировании энтропии с использованием алгоритма поиска кратчайшего пути в графе для выбора оптимального представления сжатой последовательности из общего набора вариантов.

Обратной стороной повышения коэффициента сжатия без потери совместимости является значительное повышение трудоёмкости работы алгоритма, который сжимает примерно в 100 раз медленнее zlib. Скорость распаковки архивов, созданных с использованием алгоритма Zopfli идентична другим реализациям zlib.

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

  1. Главная ссылка к новости (http://google-opensource.blogs...)
  2. OpenNews: Компания Google открыла код Snappy, библиотеки для сжатия данных
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/36267-zopfli
Ключевые слова: zopfli, gzip, zlib, deflate
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (91) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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, будет как летом на базаре в лыжи обутый.
     
     
  • 3.7, inferrna (ok), 16:59, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно, ведь текстовые данные лучше жмёт ppmd.
     
     
  • 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

    лыжи очень неплохо смотрятся.

     
  • 2.5, Аноним (-), 16:50, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И какой браузер умеет в Accept-Encoding: lzma?
     
     
  • 3.33, Алексей (??), 20:44, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=366559
     
     
  • 4.101, aborland (ok), 22:54, 05/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А какой  сервер умеет такой энкодинг отдавать?
     

  • 1.3, Аноним (-), 16:23, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    pngcrush немного улучшится теперь?
     
     
  • 2.6, Stax (ok), 16:56, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Уже - называется optipng :)
     
     
  • 3.15, Аноним (-), 19:02, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И где там новый алгоритм, а?
    http://optipng.hg.sourceforge.net/hgweb/optipng/optipng/shortlog
     
     
  • 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.78, Аноним (-), 11:57, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Блин, напутал Это optipng позволяет менять размер словаря, а advpng - ниачём ... текст свёрнут, показать
     
  • 8.90, Аноним (-), 02:50, 03/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то основное отличие advpng - там юзается не стандартная реализация deflat... большой текст свёрнут, показать
     
  • 6.72, Crazy Alex (ok), 03:20, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    лучше на imagezero гляньте - вот что надо до ума доводить...
     
     
  • 7.91, Аноним (-), 02:56, 03/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > лучше на imagezero гляньте - вот что надо до ума доводить...

    А это вообще что? И чем знаменито? А то вы так говорите как будто это все знают лучше чем гифы с пнг.

     
     
  • 8.95, Sokoloff (?), 14:45, 03/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    http www opennet ru opennews art shtml num 32940 Пока ничем не знаменито, к со... текст свёрнут, показать
     

  • 1.8, SergMarkov (ok), 17:19, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    3-8% эффективнее zlib. сжимает примерно в 100 раз медленнее zlib

    Откуда растут руки ? :-)

     
     
  • 2.10, slon (??), 17:51, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +8 +/
    а голова, откуда?
     
  • 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 насколько рано или поздно он должен забить на поиск совпадений.

     
  • 2.73, анон (?), 05:17, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    сперва добейся
     

  • 1.9, Аноним (-), 17:46, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть набор данных, в которых значений немного, но повторяемости почти никакой.
    Может кто подскажет быструю библиотечку, которая делает просто huffman, безо всякого lz.
     
     
  • 2.12, pkunk (ok), 18:43, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    bz2 ?
     
     
  • 3.25, Аноним (-), 20:04, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Медленно :(

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

     
  • 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а в веб.

     
     
  • 3.34, Michael Shigorin (ok), 20:48, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > http пакетов

    Запросов/ответов, наверное?

     
  • 3.49, Аноним (-), 22:26, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И на 3G, который отжирает батарею на трафике chrome
     
     
  • 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).

     

  • 1.16, Алексей (??), 19:19, 01/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.
     
     
  • 2.18, ip1981 (ok), 19:28, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    lzo?
     
     
  • 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.23, Аноним (-), 19:47, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    LZ4 же
     
  • 2.24, Аноним (-), 19:56, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.

    или в 100 раз лучше и на 3-8% быстрее

     
     
  • 3.39, Аноним (-), 21:10, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > или в 100 раз лучше и на 3-8% быстрее

    А с этой проблемой борется аппаратный девайс "губозакаточная машинка".

     
  • 3.93, hummermania (ok), 09:30, 03/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Бабушкин залогиньтесь
     
  • 2.38, Аноним (-), 21:09, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Лучше бы наоборот: сжимал на 3-8% хуже, но в 100 раз быстрее.

    Используйте LZO, LZ4, Snappy, quicklz, ... - и вы получите то что хотели. Ну может и не в сто раз, но до нескольких сотен мегабайтов в секунду на ядро они таки разгоняются.

     
     
  • 3.62, Аноним (-), 23:21, 01/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Но это не продукция гугл... И за это не спонсируют...
     
     
  • 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 проталкивают.

     

  • 1.80, oneonfire (?), 19:14, 02/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    https://aur.archlinux.org/packages/zopfli-git/
     
     
  • 2.81, Michael Shigorin (ok), 19:31, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > https://aur.archlinux.org/packages/zopfli-git/



      msg "Connecting to the [B]midori[/B] git repository..."

    И вот всё у них так, а потом спрашивают, зачем rpm такие сложные макросы.

     
     
  • 3.82, oneonfire (?), 20:07, 02/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Создавал на основе другого PKGBUILD, уже все исправленно...
     
     
  • 4.86, Michael Shigorin (ok), 01:40, 03/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Создавал на основе другого PKGBUILD

    Да это понятно, просто с макросами могло обойтись даже без помарки :)

    > уже все исправлено...

    Затем и сообщал.

     

  • 1.84, Аноним (-), 21:01, 02/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Для кэш-серверов это будет хорошей находкой.
     
  • 1.94, cijic (ok), 13:13, 03/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Откуда информация про "медленнее в 100 раз"?
     
     
  • 2.102, dq0s4y71 (??), 18:13, 06/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    С сайта производителя. Вчера только щупал эти zopfli, какой-то экстраординарной тормознутости не заметил. С другой стороны, я не все опции пробовал.
     
     
  • 3.103, cijic (ok), 19:12, 06/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > С сайта производителя. Вчера только щупал эти zopfli, какой-то экстраординарной тормознутости
    > не заметил. С другой стороны, я не все опции пробовал.

    Можете скинуть цитату? Я её почему-то упорно не нахожу.

     

  • 1.98, gara (??), 11:23, 04/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "жмет на 3-8% "  это только мне показалось несерьезным...

    а для скорости юзайте Parallel gzip = pigz  (http://zlib.net/pigz/)
    вроде есть в репозиториях

     
     
  • 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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру