Сжатие для исходных файлов Python - PullRequest
1 голос
/ 30 июля 2011

У меня около 700 исходных файлов Python (.py) размером в несколько килобайт (средний размер файла - 12 кБ, но также есть много файлов по 1 кБ), и я хотел бы создать сжатый архивсодержащий все из них.Мои требования:

  • Архив должен быть небольшим.(.zip файлы дают мне коэффициент сжатия 3,816, мне нужно что-то меньшее. Файл .rar, созданный с помощью rar -s -m5 a, дает мне коэффициент сжатия 6,177, я бы предпочел 7 или больше.)
  • Сжатие должно быть без потерь, оно должно сохранять исходный файл побитно.(Таким образом, минификация отсутствует.)
  • Должна быть небольшая библиотека, написанная на C, которая может перечислять архив и извлекать отдельные файлы.
  • Библиотека декомпрессии должна быть быстрой, то есть не намного медленнее, чемzlib, желательно быстрее.
  • Если я хочу извлечь один файл, мне не нужно распаковывать большие несвязанные части архива.(Таким образом, сжатые файлы .tar отсутствуют, а файлы .rar отсутствуют.)
  • Поскольку все файлы .py имеют небольшой размер (всего несколько килобайт), мне не нужна потоковая передачараспаковка или поиск поддержки в файле.
  • Если возможно, распаковка должна быть инициализирована из контекстного словаря, сгенерированного из объединения файлов .py, чтобы сэкономить больше места.

Какой алгоритм сжатия и библиотеку декомпрессии C вы порекомендуете?

Я знаю о концепции минимизации кода (например, удаление комментариев и лишних пробелов, переименование локальных переменных в одну букву), и я рассмотрю возможность использования этого метода длянекоторые из моих .py файлов, но в этом вопросе меня это не интересует.(См. Python minifier здесь .)

Я знаю о концепции компиляции байт-кода (.pyc файлы), но в этом вопросе меня это не интересует.(Причина, по которой я не хочу иметь байт-код в архиве, заключается в том, что байт-код зависит от архитектуры и версии, поэтому он менее переносим. Кроме того, .pyc файлы, как правило, немного больше, чем уменьшенные .py файлы.)

См. Мои ответы, содержащие план B и план C. Я все еще ищу план A, который меньше, чем ZIP (но, скорее всего, он будет больше, чем .tar.xz), и у него меньше накладные расходы, чем .tar.xz.

Ответы [ 3 ]

3 голосов
/ 30 июля 2011

Я знаю, что вы отклонили .zip, но это может изменить ваше решение, если вы поймете, что Python уже способен импортировать пакеты прямо из zip-файлов в форме файлов egg. Дополнительный код не требуется, за исключением файла конфигурации setuptools.

2 голосов
/ 30 июля 2011

Вы должны рассмотреть LZMA (также см. C SDK ).

0 голосов
/ 10 сентября 2013

FYI Plan B - это просто использование ZIP-файлов. Вот чем я сейчас занимаюсь. Хранение .py файлов в ZIP-архивах очень удобно для Python, поскольку Python может загружать .py файлы непосредственно из ZIP-архивов. Но мне нужно что-то меньшее, чем ZIP-файл, поэтому я и задал вопрос.

FYI Plan C должен использовать .tar.xz. Вот анализ. Ядро Linux и Busybox 1.8.5 содержат декомпрессор .xz, который компилирует до 18 КБ кода x86, что соответствует моему требованию небольшой библиотеки декомпрессии. .tar.xz с xz -6 -C crc32 дает степень сжатия 6,648 для файла .tar. Издержки декомпрессора .xz Busybox 1.8.5, скомпилированного для x86, составляют 17840 байт в размере кода (сравнение исполняемого файла с файлом .tar.xz). Так что это план C: когда исполняемый файл запускается, распакуйте весь архив в память. (Это занимает около 0,35 секунды на моем компьютере, выходной файл занимает 9 МБ памяти). Чтобы прочитать файл из архива, используйте его несжатое представление в памяти. Это будет очень быстро. Этот план резервного копирования не является решением моей проблемы, поскольку в начале выполнения он требует 0,35-секундной нагрузки и требует 9 МБ дополнительной памяти.

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