2010-03-07 4 views
6

Мне нужно выбрать алгоритм сжатия для сжатия некоторых данных. Я не знаю тип данных, которые я буду сжимать заранее (подумайте об этом как о программе WinRAR).Мне нужно выбрать алгоритм сжатия

Я слышал о следующих алгоритмах, но не знаю, какой из них я должен использовать. Может ли кто-нибудь опубликовать короткий список плюсов и минусов? Для моего приложения первым приоритетом является скорость декомпрессии; второй приоритет - сохранение пространства. Скорость сжатия (не декомпрессии) не имеет значения.

  • выкачивает
  • Implode
  • Plain Хаффмана
  • bzip2
  • LZMA
+0

Некоторые языки имеют встроенную поддержку для некоторых (возможно все) из них, так что вы можете сделать небольшое тестирование. Я думаю, это сложно, если вы не знаете тип данных, которые собираетесь сжимать, но, надеюсь, у вас есть * какая-то идея или какой-то случай случайного генерирования данных это близко к тому, что вы будете использовать, в некотором роде. – MatrixFrog

+0

это «некоторые данные»? Любой подсказку? – fazo

ответ

5

Если вам нужна высокая скорость декомпрессии, то вы должны использовать LZO. Его скорость и коэффициент сжатия достойны, но его скорость декомпрессии очень тяжелая.

+0

wow thanks! Никогда не слышал об этом раньше, но, похоже, именно то, что я ищу. – chiz

1

Для исчерпывающего эталона текстовых данных вы можете проверить Large Text Compression Benchmark.

Для других типов, this might be indicative.

+0

А как насчет других типов данных? – Gumbo

+0

@Gumbo: thx, обновлено. –

+0

Однако я должен добавить, что это обычно зависит от данных. (Вот почему это только * индикативный *.) –

4

В Linux ядре хорошо объяснено (от включенного):

  • выкачивает (GZIP) - быстрое, худшее сжатие
  • bzip2 - медленное, среднее сжатие
  • LZMA - Очень медленно сжатие , быстрая декомпрессия (однако медленнее, чем gzip), лучшее сжатие

Я не использовал других, так что сказать трудно, но скорость алгоритмов может зависеть в значительной степени от архитектуры. Например, существуют исследования того, что сжатие данных на жестком диске ускоряет ввод-вывод, поскольку процессор намного быстрее, чем тот диск, который он стоит. Однако это во многом зависит от размера узких мест.

Аналогично, один алгоритм может широко использовать память, что может или не может вызвать проблемы (12 MiB - это много или очень мало? На встроенных системах это очень много: на современном x86 это крошечный фрагмент Память).

+2

Обратите внимание, что * deflate * - это * формат данных * while * gzip * - * формат файла *, который использует * deflate * для сжатия файлов. – Gumbo

+0

Опция в ядре Linux называется gzip (как сжать ядро ​​/ initrd). Поэтому я включил его также. –

2

Посмотрите на 7zip. Это открытый исходный код и содержит 7 отдельных методов сжатия. Некоторое небольшое тестирование, которое мы сделали, показывает, что формат 7z дает намного меньший файл результата, чем zip, и он также был быстрее для данных образца, которые мы использовали.

Поскольку наше стандартное сжатие - это zip, мы еще не рассматривали другие методы сжатия.

+0

Формат 7zip AFAIK является LZMA (перечисленным выше). –

10

Я запустил несколько тестов, сжимающих .tar, которые содержали смесь высоких данных энтропии и текста. Это результаты:

 
Name - Compression rate* - Decompression Time 
7zip - 87.8%    - 0.703s 
bzip2 - 80.3%    - 1.661s 
gzip - 72.9%    - 0.347s 
lzo - 70.0%    - 0.111s 

*Higher is better 

Из этого я пришел к выводу, что степень сжатия алгоритма зависит от его имени; первый в алфавитном порядке будет тот, у которого максимальная степень сжатия, и так далее.

Поэтому я решил переименовать lzo в 1lzo. Теперь у меня есть лучший алгоритм.


EDIT: Стоит отметить, что из всех из них, к сожалению, lzo является единственным с очень ограничительной лицензией (GPL) :(

+0

+1 для потрясающего открытия! Похоже, что это справедливо и для сжатия видео, но в обратном направлении: x264> XviD> DivX;) (сортировка по регистру;)) –

+1

«очень ограничительная лицензия (GPL)» -/me возрождает вековую BSD vs Аргумент GPL: ограничительный для вас разработчик, но не для конечного пользователя! :) –

Смежные вопросы