Сколько данных требуется при сжатии текстовых файлов с помощью DEFLATE, прежде чем станет возможным уменьшение размера?
Степень сжатия, достигаемая любым алгоритмом сжатия, очевидно, зависит от предоставленных данных. Тем не менее, очевидно, что некоторые накладные расходы добавляются исключительно благодаря сжатию данных.
Я работаю над процессом, в котором я сжимаю данные, которые могут быть разных типов, но я знаю, что большая часть данных будет очень маленькой, хотя она также часто будет достаточно большой, чтобы извлечь выгоду из некоторого уровня сжатия. Хотя я, вероятно, могу просто экспериментально определить некоторый минимум перед применением сжатия, который будет работать достаточно хорошо, мне любопытно, есть ли четкий момент, когда это определенно не стоит того.
Выполнив несколько тестов с использованием zip, я сжал серию файлов с 10, 100 и 1000 байтами соответственно случайных данных и повторения алфавита. Например, вот содержимое 100-байтового файла алфавита:
abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqr
Я был довольно удивлен, обнаружив, что заархивированная версия файла имеет размер 219 байт, несмотря на уровень избыточности. Для сравнения 100-байтовый файл со случайными данными стал 272-байтовым.
Однако 1000-байтовый файл с алфавитом был полностью сжат до 227 байт, а случайный файл увеличился до 1174.
Существует ли четкий минимальный размер файла, при котором даже самые избыточные файлы не выиграют от этого типа сжатия?
Ответы 1
Что-то между 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 кажется фиксированной точкой для этого типа файлов.
Наконец, я решил попробовать более прямой подход с текстом lorem ipsum и в конце концов обнаружил, что 414 байт были фиксированной точкой.
Основываясь на всем этом, я бы предположил, что что-то между 250 и 500 будет разумным нижним пределом для пропуска сжатия для обычного текста, который может иметь или не иметь в среднем некоторый уровень избыточности. Можно даже захотеть подняться выше, если бенчмаркинг покажет, что время, затрачиваемое на сжатие, не стоит незначительного преимущества в пространстве.
Если я сделаю
zip -9 abc.zip abc.txtс вашим примером, Deflate уменьшит его до 33 байт (вы видите это сunzip -v abc.zip). Остальное — это метаданные, относящиеся к файлу abc.txt (его имя, отметка времени и т. д.).