Я ищу алгоритм для распаковки кусков данных (1k-30k) в реальном времени с минимальными накладными расходами. Сжатие предпочтительно должно быть быстрым, но не столь важным, как скорость декомпрессии.Самый быстрый алгоритм декомпрессии реального времени
Из того, что я мог собрать, LZO1X был бы самым быстрым. Я что-то пропустил? В идеале алгоритм не находится под GPL.
Если вы не можете использовать лицензионный код GPL, ваш выбор будет ясным - zlib. Очень разрешительная лицензия, быстрое сжатие, справедливая степень сжатия, очень быстрая декомпрессия, работает повсюду и портируется на любой здравомыслящий язык.
Эта статья: http://www.kkant.net/papers/lzo_results.pdf требует 20-кратного ускорения скорости LZO против zlib (конечно, с ухудшением характеристик сжимаемости). – MaR
Да, zlib хорош во многих вещах, но он не самый лучший на скоростях декомпрессии. У меня было что-то вроде QuickLZ. – 2010-03-20 11:07:42
Как соавтор zlib и поддерживающий zlib, могу сказать, что это не очень хороший ответ на этот вопрос. Есть гораздо более быстрые декомпрессоры, если вы допускаете менее эффективное сжатие. –
Попробуйте Google Snappy.
Snappy - это библиотека сжатия/декомпрессии. Он не предназначен для максимального сжатия или совместимости с любой другой библиотекой сжатия; вместо этого он предназначен для очень высоких скоростей и разумного сжатия. Например, по сравнению с самым быстрым режимом zlib, Snappy на порядок быстрее для большинства входов, но полученные сжатые файлы от 20% до 100% больше. На одном ядре процессора Core i7 в 64-битном режиме Snappy сжимается со скоростью около 250 МБ/с и более и распаковывается со скоростью около 500 МБ/с или более.
Юку, мы наблюдаем скорость декомпрессии 10-12Mb/sec (vs 500Mb/s, заявленная на wiki), запуская 'hadoop -text $ {snappy_compressed_file}'. Установлены собственные библиотеки Hadoop (в том числе snappy native). Есть предположения? Наша информация о процессоре (Amazon EMR) Intel (R) Xeon (R) CPU E5645 @ 2.40GHz –
Мое собственное приложение работает на 1,2 ГГц Процессор ARMv7 распаковывает данные 5 МБ в 100 мс. Вы распаковывались из памяти или накладные расходы ввода-вывода? – yuku
Спасибо за обмен, Юку. Однако задействован ввод-вывод, накладные расходы весьма незначительны по сравнению с декомпрессионным ударом. Ниже приведен один и тот же вопрос с более подробной информацией о быстрой группе google: http://goo.gl/LBapFc –
lz4 - это то, что вы ищете здесь.
LZ4 является алгоритм сжатия без потерь, обеспечивая скорость сжатия при 400 Мбайт/с на ядро, масштабируемых с мульти-ядер процессора. Он оснащен чрезвычайно быстрым декодером со скоростью в несколько Гбайт/с на ядро, обычно достигает пределов скорости RAM в многоядерных системах.
Декомпрессия чего? Файлы? Потоки? IP-пакеты? Видео? Какая кодировка? –
Не будет ли сжатие самым быстрым сжатием? –
@JensSchauder: Определенно нет. Если декомпрессия превышает скорость RAM (например, распаковка в кеш L2/L3), вы можете добиться большей скорости путем сжатия, чем без нее. При использовании диска или сети преимущество сжатия может быть еще больше. –