При сжатии текстовых файлов с помощью DEFLATE, сколько данных требуется для уменьшения размера? - PullRequest
Новая
       42

При сжатии текстовых файлов с помощью DEFLATE, сколько данных требуется для уменьшения размера?

1 голос
/ 31 мая 2019

Степень сжатия, достигаемая любым алгоритмом сжатия, очевидно, зависит от предоставленных данных. Тем не менее, очевидно, что некоторые издержки добавляются исключительно за счет сжатия данных.

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

Запустив некоторые тесты с использованием zip, я сжал серию файлов с 10, 100 и 1000 байтов соответственно случайных данных и повторения алфавита. Например, вот содержимое файла 100-байтового алфавита: 

abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqr

Я был довольно удивлен, обнаружив, что сжатая версия файла имеет размер 219 байт, несмотря на уровень избыточности. Для сравнения 100-байтовый файл со случайными данными стал 272 байта.

Однако 1000-байтовый алфавитный файл сжимался до 227 байт, а случайный файл увеличивался до 1174.

Существует ли четкий минимальный размер файла, когда даже самые избыточные файлы не получат преимущества от этого типа сжатия?

1 Ответ

1 голос
/ 31 мая 2019

Что-то между 250 и 500 байтами было бы достойным порогом в зависимости от уровня избыточности и с учетом того, что время, потраченное на сжатие данных, незначительно.

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

Повторный запуск тех же тестов с данными, считанными из /dev/zero, я обнаружил, что длина сжатого файла былана самом деле не та переменная: 

Uncompressed | Compressed | Percent Size
-------------+------------+-------------
100 bytes    | 178 bytes  | 178% 
200 bytes    | 178 bytes  |  89%
300 bytes    | 179 bytes  |  60%
400 bytes    | 180 bytes  |  45%
500 bytes    | 180 bytes  |  36%
  ...
1000 bytes   | 185 bytes  |  19%

Это достойный аргумент в пользу того, что ответ технически 178 байт (я проверял этот случай и получил 178 байт).

ОднакоЯ думаю, что алфавитный тест, вероятно, немного ближе к практическому наилучшему случаю избыточности (не зная, как DEFLATE выглядит для избыточности).

Использование различных файлов в том же формате, что и в вопросе, я обнаружилследующее: 

Uncompressed | Compressed | Percent Size
-------------+------------+-------------
100 bytes    | 212 bytes  | 212% 
200 bytes    | 212 bytes  | 106%
300 bytes    | 214 bytes  |  71%
400 bytes    | 214 bytes  |  54%
500 bytes    | 214 bytes  |  43%
  ...
1000 bytes   | 221 bytes  |  22%

И неудивительно, что 212 представляется фиксированной точкой для этого типа файла.

Наконец, я решилo попробовать более прямой подход с текстом lorem ipsum и в итоге обнаружил, что фиксированная точка там была 414 байт.

Исходя из всего этого, я бы предположил, что что-то между 250 и 500 будет разумным нижним пределом для пропускасжатие для общего текста, который может иметь или не иметь некоторый уровень избыточности в среднем.Кто-то может даже захотеть подняться выше, если сравнительный анализ покажет, что время сжатия не стоит незначительной выгоды в космосе.

...