Отправка текстового файла по сети с высокой степенью сжатия - PullRequest
2 голосов
/ 12 сентября 2009

У меня есть текстовый файл, который я хочу отправить по сети, его размер может варьироваться от 1 до 500 КБ.
Какие алгоритмы / методы можно использовать, чтобы плотно сжать этот файл перед его отправкой, чтобы наименьшее количество байтов отправлялось по сети, а степень сжатия была высокой?

Ответы [ 3 ]

6 голосов
/ 12 сентября 2009

Для сжатия я бы рассмотрел gzip, bzip2 и LZMA (это не исчерпывающий список, но это IMO - самый известный).

Затем я посмотрю на некоторые тесты в сети и попытаюсь собрать показатели для различных типов файлов (текстовые, двоичные, смешанные) и размера (маленький, большой, огромный). Даже если вас больше всего интересует степень сжатия, вы можете посмотреть: степень сжатия, время сжатия, объем памяти, время распаковки .

Согласно Быстрый тест: Gzip против Bzip2 против LZMA :

[...] gzip очень быстрый и занимает мало памяти. Согласно этому тесту, ни bzip2, ни lzma не могут конкурировать с gzip с точки зрения скорости или использования памяти. bzip2 имеет заметно лучшую степень сжатия, чем gzip, что должно быть причиной популярности bzip2; это медленнее, чем gzip, особенно при распаковке и использует больше памяти. Однако требования к памяти bzip2 в настоящее время не должны вызывать проблем даже на устаревшем оборудовании.

[...]

LZMA явно может стать третьим широко используемым форматом сжатия общего назначения в системах * NIX. Он в основном конкурирует с bzip2, предлагая значительно лучшую степень сжатия, сохраняя скорость распаковки относительно близкой к gzip.

Это подтверждается в LZMA - лучше, чем bzip2 :

Описание впечатляет, в Короче говоря:

  • Лучшая степень сжатия (с лучшим уровнем сжатия при gzip достигает 38%, bzip2 34%, LZMA имеет 25%). * +1027 *
  • Сжатие коэффициента усиления наблюдается в основном на двоичных файлах .
  • Время распаковки намного быстрее (в 3-4 раза), чем bzip2.
  • Алгоритм позволяет выполняться параллельно (но инструмент Я опишу вот это как-нить).

Есть и недостатки:

  • Сжатие (исключая более низкие уровни) намного медленнее, чем bzip2.
  • Требования к памяти во время сжатия намного выше, чем для bzip2.

Итак, для сжатия текстовых файлов тот же сайт сообщает:

Первым делом я использовал LZMA для сжатие моего почтового архива. Спам файл (почта в формате mbox) я выбрал 528MB большой, и я буду использовать максимум степень сжатия. Во время сжатия Процесс lzma был большой 370MB, это много :) bzip2 был ниже 7МБ. Это заняло почти 15 минут, чтобы сжать файл от lzma и менее чем за 4 минуты bzip2. Коэффициент сжатия был очень аналогично: выходной файл для 373MB bzip2 и 370MB для lzma. Время распаковки 1m12s для lzma и 1m48s для bzip2.

Наконец, еще один ресурс с графическими результатами: Инструменты сжатия: lzma, bzip2 & gzip

Я бы порекомендовал провести собственный тест (поскольку вы будете сжимать только текст и очень маленькие файлы в небольшие), чтобы получить реальные метрики в вашей среде, но я уверен, что LZMA не обеспечит существенное преимущество для небольших текстовых файлов, поэтому bzip2 будет достойным выбором (даже если время и объем памяти LZMA могут быть небольшими для небольших файлов).

Если вы планируете выполнить сжатие из Java, вы найдете реализацию LZMA здесь , реализацию bzip2 здесь (из Apache Ant AFAIK), gzip будучи включенным в JDK. Если вы не хотите или не можете полагаться на стороннюю библиотеку, используйте gzip.

4 голосов
/ 12 сентября 2009

Ответ зависит от содержания. GZip включен в JDK. Тесты на случайных строках в среднем уменьшаются на 33%.

[редактировать: содержание, а не контекст]

0 голосов
/ 12 сентября 2009

Это зависит. Можете ли вы контролировать размер сетевого пакета? Собираетесь ли вы связать их, если в пакет поместится более 1? Вы ограничены процессором на обоих концах? Не совсем вопрос, но все же связанный, поскольку сжатие и распаковка может занять больше времени, чем время от времени отправка байтов.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...