uShell
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| А зачем останавливаться на 258? |
Я думал, что GZip поддерживает исключительно Deflate, но не Deflate64. Разве не так?
Цитата:| А есть вообще инфа, почему зарезано так? Какие причины? |
Павлов пишет, что ему было влом возиться с алгоритмом генерации дополнительных кодов в Deflate-потоке. Правда, я не всё понял (например, он пишет про 5-битный дополнительный код для fb258 (слово 285 по RFC 1951), хотя в RFC 1951 он только 0-битный*), но всё сводится к тому, что надо переделывать старый код, а он этого не хочет.
В том же посте есть и предположение, почему fb257 медленнее fb256. В версии 25.00 я такого замедления не замечал. А вот пояснение насчёт генерации дополнительных кодов заставляет предположить, что для слова 285 используется отдельная ветка кода, и она хуже оптимизирована.
Кстати говоря, раз BT5/HC5 умеют отдельно обрабатывать длинные последовательности нулей, было бы нелишним передавать соответствующую информацию в 7-Zip, чтобы для Deflate/Deflate64 и LZMA2 на такие последовательности генерировался заранее оптимизированный блок с максимальным сжатием. Но, увы, это тоже будет усложнением кода.
*Поправка. Перечитал RFC 1951 и с удивлением обнаружил, что в кодовом слове 284 действительно можно закодировать длину 258.
Между тем, Игорь Павлов пояснил, что работает над оптимизацией кода сжатия Deflate. Посмотрим, что из этого получится. |
Всего записей: 1162 | Зарегистр. 12-06-2019 | Отправлено: 20:43 22-07-2025 | Исправлено: uShell, 17:19 29-07-2025 |
|
