The OpenNET Project / Index page

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

Сравнение производительности и степени сжатия gzip, bzip2 и lzma

27.03.2009 13:35

"GZIP vs. BZIP2 vs. LZMA" - сравнение производительности и степени сжатия gzip 1.3.12, bzip2 1.0.5, LZMA 4.32.0beta3.

Сжатие пустого файла, размером 1Гб, состоящего из нулей:

  • GZIP: 12.36 сек. CPU 99%, 1018 Кб
  • BZIP2: 32.07 сек. CPU 98%, 785 байт (!)
  • LZMA: 873.79 сек. CPU 96%, 148 Кб

Сжатие архива системных файлов (120 Мб):

  • GZIP: 19.42 сек CPU 89%, 39 Мб
  • BZIP2: 30.76 сек. CPU 93%, 36 Мб
  • LZMA: 132.21 сек. CPU 92%, 25 Мб (!)

Сжатие видеофайла (175 Мб):

  • GZIP: 10.94 сек. CPU 78%, 173 Мб
  • BZIP2: 55.15 сек. CPU 94%, 173 Мб
  • LZMA: 138.74 сек. CPU 93%, 174 Мб


  1. Главная ссылка к новости (http://odzangba.wordpress.com/...)
  2. OpenNews: Сравнение эффективности сжатия файлов программами Gzip, Bzip2 и Lzma
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/20958-compress
Ключевые слова: compress, benchmark, bzip, lzma, bzip2
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (23) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 13:48, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Гзип по скорости заруливает всех.
     
     
  • 2.2, аноним (?), 14:09, 27/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Гзип по скорости заруливает всех.

    На сжатие. Распаковывает lzma по-прежнему быстрее.

     
  • 2.11, User294 (ok), 19:21, 27/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Гзип по скорости заруливает всех.

    Ну и жмет дохлее всех, соответственно.Если смириться с еще более дохлым сжатием, LZO или QuickLZ по скорости порвут гзипа играючи (у них декомпрессия вообще обычно упирается в скорость работы дисков, но зато и сжатие еще хилее :P).

    А тест довольно тупой.Например, нули давить - не показательно, синтетика в хучшем виде.А в среднем по больнице - bzip2 имхо можно закапывать: жмет заурядно и медленно.Декомпрессится тоже медленно.LZMA хоть и тормозно жмет но зато - жмет сильно и декомпрессится быстро.Более того - на реальных наборах данных LZMA почти всегда уделывает bzip2 по степени сжатия.Зачастую достаточно заметно.

     

  • 1.3, goshanecr (??), 14:15, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А может кто нибудь сказать почему пустой файл сжимается аж в 148 килобайт? Там образно говоря разве нельзя записать что последовательность из миллиарда элементов и единичный элемент байт 0? Ну сотня байт.. но не сто же килобайт то..
     
     
  • 2.4, Sem (??), 14:56, 27/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    bzip2 примерно так и сделал.
     
  • 2.5, Ыку (?), 14:57, 27/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >А может кто нибудь сказать почему пустой файл сжимается аж в 148
    >килобайт? Там образно говоря разве нельзя записать что последовательность из миллиарда
    >элементов и единичный элемент байт 0? Ну сотня байт.. но не
    >сто же килобайт то..

    Все зависит от размера словаря. Чем он больше тем больше повторений можно поймать и тем меньше будет количество служебной информации.

     
  • 2.19, User294 (ok), 15:22, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну сотня байт.. но не сто же килобайт то..

    В таком предельном случае всех зарулит обычное примитивное RLE-кодирование, суть которого сводится к тому что сохраняется счетчик повторов и то чего повторять.Так можно пару миллиардов нулей тиснуть в десяток байтов, если поюзать оптимизированный вариант RLE с счетчиком должной разрядности (его должно хватить на сохранение числа "пара миллиардов").Проблемы будут тогда когда на вход подадут не нули а реальные данные - там конечно блоки заполненые одинаковыми байтами бывают но - достаточно немного, так что эффективность RLE на более полезных реалистичных данных - отвратная :)

    А алгоритмы типа LZMA более заточены на реалистичное использование на типичных реальных данных.Никто не ставит там себе задачу всех уделать на последовательности из миллиарда нулей.Ну вот оно себя и показывает на реальных данных, даже этот странный и стремный писькомер это выловил.

     

  • 1.6, Andrew Kolchoogin (?), 15:02, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Плохой, негодный тест. У 7z, использующего алгоритм LZMA для сжатия, заметно побольше ключей для достижения максимальной компрессии. У меня есть ощущение, что размер словаря не раскачали до максимума.
     
     
  • 2.20, User294 (ok), 15:34, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >словаря не раскачали до максимума.

    Зависит от хардвара ;).А вдруг у них оперативки было мало?А еще они поюзали дреееееееееевний вариант LZMA - 4.4х версий.При текущей версии LZMA SDK всего-то 4.65 ... oO

     

  • 1.7, Konwin (??), 15:10, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что любопытно - сколько раз сам что-то жал - не получалось у меня чтоб в 7Zip с LZMA было медленнее чем в нём же с BZip2...
     
     
  • 2.9, Angel IL (?), 16:20, 27/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Аттож, и у меня не получалось бзипом сжать быстрее чем жмет 7зип... что то, кто то, где то врет...
     
  • 2.22, User294 (ok), 23:07, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Подсказать как тормознуть 7zip или сами догадаетесь? :)
    Хинт: в 7zip можно указывать длину совпадений которая "устраивает" искалку совпадений, так что он будет до упора искать длииииинные совпадения.Это тормознет сжатие и улучшит его (если в входных данных есть совпадения длиннее чем заданная величина).Кстати в клинических случаях типа "миллиард нулей" задирание этой величины может заметно улучшить степень сжатия.На практически ценных данных выигрыш от выкручивания этого параметра обычно не особо большой а вот тормозов он добавляет конкретно.

    Хинт2: в графическом виндовом варианте можно покрутить fast, ... normal, ... ultra и посмотреть чем отличаются их параметры :).Отличие там не только в словаре...

     

  • 1.8, Ivan (??), 16:18, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Сжатие видеофайла (175 Мб) ...

    Надо было несжатый AVI-файл сжимать, тогда результат нёс бы хоть какую-то информацию.

     
  • 1.10, Serega (??), 19:16, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а системные файлы == текстовые конфиги?
     
  • 1.12, pavlinux (ok), 19:34, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сдаётся мне,  что у него диск тормозил!

     
  • 1.13, frol (??), 19:40, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По-моему бессмысленный бенчмарк.

    Насколько я понимаю, алгоритм LZMA силен не скоростью сжатия, а скоростью распаковки. Где соответствующий бенчмарк?

    Могу также предположить, что compress обгонит gzip по скорости на всех проведенных  тестах.

     
     
  • 2.23, User294 (ok), 23:08, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Могу также предположить, что compress обгонит gzip по скорости на всех проведенных
    > тестах.

    А уж lzop использующий LZO и вовсе всех порвет.Правда вот он и жмет хуже чем gzip - чудес не бывает...

     

  • 1.14, pavlinux (ok), 20:37, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    $  time -f "%U seconds CPU %P" gzip -c9 BIGNULL > BIGNULL.gz

    112.66 seconds CPU 95%

    $ time -f "%U seconds CPU %P" bzip2 -c9 BIGNULL > BIGNULL.bz2

    271.56 seconds CPU 96%

    $ time -f "%U seconds CPU %P" mksquashfs ./BIGNULL  BIGNULL.sqsh -no-recovery -no-exports -no-progress -no-sparse -processors 4 -all-root -nopad

    166.24 seconds CPU 161%

    $ time -f "%U seconds CPU %P" lzma --threads=4 -c9 BIGNULL > BIGNULL.lzma

    1416.45 seconds CPU 97%

    $ time -f "%U seconds CPU %P" rar a -m5 -s BIGNULL.rar BIGNULL

    762.87 seconds CPU 98%


    ~> ls -la BIGNULL*

    -rw------- 1 pavel users 8589918208 Мар 27 19:31 BIGNULL
    -rwx------ 1 pavel users    9766216 Мар 27 20:13 BIGNULL.sqsh
    -rw------- 1 pavel users    8336307 Мар 27 19:43 BIGNULL.gz
    -rw------- 1 pavel users     581249 Мар 27 20:32 BIGNULL.rar
    -rw------- 1 pavel users     280375 Мар 27 20:11 BIGNULL.lzma
    -rw------- 1 pavel users       6034 Мар 27 19:51 BIGNULL.bz2

     
     
  • 2.21, Анонимус (?), 16:19, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ЦПУ 161% - это как? Многопоточность???
     

  • 1.15, Аноним (-), 21:27, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Выходит, самым оптимальным видится BZIP2. LZMA еще не дорос по параметрам "цена/качество"
     
     
  • 2.16, tamerlan311 (?), 22:44, 27/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Выходит, самым оптимальным видится BZIP2. LZMA еще не дорос по параметрам "цена/качество"
    >

    Дорос, тут тестировали LZMA видимо с максимальным сжатием, на с жатии с коэффициентом 2 LZMA как правило делает bzip2 и по скорости и по коэффициенту.

    http://tukaani.org/lzma/benchmarks

    Вот более адекватный тест.

     

  • 1.17, yantux (??), 23:23, 27/03/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А 7z?

    Не давно стал пробовать - мне нравиться больше, чем bzip2. Потому что быстрее, а степень сжатия отличается не супер сильно.

     
     
  • 2.18, викиочевидность (?), 00:23, 28/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    lzma
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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