В текущих реалиях кризиса ОЗУ и флеш‑накопителей, затронувшего всю электронику, многие пользователи компьютеров и ноутбуков не могут позволить себе покупку новой электроники или даже апгрейд SSD. SSD на 256ГБ остаются в пределах досягаемости по цене из‑за их распространённости, но ими уже почти никто не хочет пользоваться, потому что современные программы и игры стали занимать ну очень много места на диске, и 256-гигабайтные SSD очень легко забить. А как известно, выше 90% ёмкости у SSD занимать в долгосрочной перспективе крайне не рекомендуется из‑за сильного и быстрого износа блоков памяти, который будет происходить в будущем — эффект будет как от иглы, которая проделает дыру, протыкая очень маленькую площадь. Так же будет и с SSD, в котором быстро образуется дыра в лице убитых блоков памяти, и он станет непригодным к использованию, если его забить донельзя.
Что можно сделать
Раньше, программистам приходилось умещать программы в очень небольшие пространства на дисках и в ОЗУ. Среднестатистический картридж у игровых приставок содержал от 1 до 4 мегабит данных, или от 128КБ до 512КБ. Сейчас же современные программы и игры (теперь нередко состряпанные с помощью ИИ) занимают гигабайты памяти и требуют огромных мощностей от железа, при этом работают они значительно медленнее, чем старые программы на старом железе.
Всё, что поменялось — делать такие программы теперь можно чуть быстрее и можно нанимать менее компетентных программистов. А все минусы, типа неоптимизированных алгоритмов, кучи ненужных зависимостей и упущений программистов, покроет пользователь — он оплатит покупку дорогого и мощного компьютера, который это всё вытянет.
«Самое удивительное достижение индустрии программного обеспечения — в том, что она постоянно нивелирует ошеломляющие успехи производителей аппаратного обеспечения» — Генри Петроски
Но уже в 90-х годах программистам пришлось научиться сжимать данные на дисках — у тех же игр приходилось сжимать код, текстуры, анимации, а затем и видеоролики. Capcom лидировала в этой сфере — в 1996 году они выпустили Street Fighter Alpha 2 для Super Famicom, использующую чип для распаковки сильно сжатых данных налету, чтобы уместить игру, занимавшую 224 мегабита на аркадном железе CPS‑II, на 32-мегабитном картридже SNES. А в 1998 вместе с Angel Studios, Capcom выпустила порт Resident Evil 2 на Nintendo 64, где диск с 650МБ данных удалось сжать до 64МБ.
Когда вы скачиваете любую программу из интернета, она предоставляется в файле.exe,.msi,.zip (с последующей распаковкой) и в других форматах — но после установки, программа превращается из 100МБ в 300–400МБ. А разве нельзя сделать так, чтобы 100МБ были близки к 100МБ? Что мешает этому? На самом деле, мешает только незнание того, что эти данные программ можно сжать. А как их сжимать?
Как это делалось
Минутка истории.
В Windows XP появилась файловая система NTFS. Из множества плюсов NTFS, которая во всю используется по сей день (а прошло уже 25 лет), выделяется возможность сжатия файлов на уровне файловой системы. Это работает так: данные в файле делятся на блоки по 64 КБ. Каждый такой блок сжимается независимо алгоритмом LZNT1 и помечается, как сжатый. При чтении драйвер NTFS автоматически распаковывает нужные блоки на лету, а при записи — сжимает заново. Для приложений этот процесс невидим, но фактический объём занимаемого программами места на диске становится меньше — а сам процесс не приводит к потере информации.
Когда вы открываете свойства диска в Проводнике, вам даётся возможность сжимать диск для экономии места. Именно здесь и используется алгоритм LZNT1 для сжатия данных. Причём этот алгоритм использовался от Windows XP и используется по сей день даже в самых новых версиях Windows 11.
Но нажимать на этот флаг не надо. Как всегда, программисты Microsoft внедрили полу‑меры, но до ума эту технологию не довели, чтобы сжимать данные по‑умному, а не всё, что попало. LZNT1 — слабый и устаревший алгоритм по сегодняшним меркам, а из‑за сжатия всего подряд, у вас без причин увеличится нагрузка на процессор и замедлится система. А если у вас по сей день используется жёсткий диск вместо SSD, то фрагментации диска не миновать. Для SSD же это безпорядочное и постоянное сжатие означает дополнительный износ ячеек памяти.
В macOS идентичное прозрачное сжатие файлов на уровне файловой системы HFS+ (впервые появилась в macOS 8.1) добавили в версии OS X 10.6 Snow Leopard через механизм decmpfs. Позже, в macOS 10.13 High Sierra, на смену пришла APFS (Apple File System), которая унаследовала и продолжает поддерживать то же сжатие. В отличие от NTFS, где сжатие глубоко интегрировано в структуру кластеров файла и может смешивать сжатые и несжатые куски внутри одного файла, у Apple сжатие ориентировано не на блоки, а на файлы, через метаданные.
В Linux похожий функционал есть в современных файловых системах. btrfs и ZFS поддерживают прозрачное сжатие алгоритмами lz4, zstd, gzip и др. Его можно включить для всего раздела или избирательно, и иногда это даже ускоряет работу, потому что уменьшается объём чтения/записи с диска. Для работы с уже сжатыми NTFS‑томами из‑под Linux есть поддержка в драйверах ntfs3.
Как это делается теперь
Спасение идёт от сторонних утилит от энтузиастов с открытым исходным кодом:
Для macOS — applesauce.
Она умеет сжимать, разжимать и показывать информацию о файлах на HFS+ и APFS. Поддерживает три алгоритма Apple: LZFSE (он специально для процессоров M‑серии, тоесть Apple Silicon), LZVN и ZLIB. Раньше использовался afsctool, но в отличии от него, эта утилита параллелит процесс сжатия даже внутри одного файла, меньше жрёт памяти, показывает нормальный прогресс и безопасно пишет через временный файл с атомарным переименованием. Интерфейса с кнопками нет, делается всё через терминал: applesauce compress -c LZFSE <директория>.
Для Linux, самое близкое — это Btrfs Assistant для файловых систем btrfs, потому что в Linux сжатие живёт глубже — внутри самих файловых систем. В btrfs и ZFS его включают при монтировании опцией compress=zstd:1 в fstab или mount, или выборочно для конкретных файлов и папок командами chattr +c и btrfs property set. Для уже записанных данных запускают дефраг с флагом сжатия: btrfs filesystem defrag -czstd -rv <путь>. Посмотреть реальную экономию пространства на диске помогает утилита compsize.
Btrfs Assistant косвенно помогает, но само сжатие чаще настраивают через терминал или при установке системы. Выборочное сжатие отдельных директорий, отдельных игр, с умным выбором алгоритма — даже если осуществимо, то только через скрипты.
А для ОС Windows, которые в этой сфере лидируют, всё проще для обычного пользователя.
В Windows 10 добавили утилиту compact.exe, с которой стало возможно сжатие индивидуальных файлов, Это привело к созданию энтузиастами таких программ:
trash‑compactor (самая актуальная, созданная мной — о ней чуть позже)
compactor (устарела)
Самая известная, однако не самая лучшая — CompactGUI. Эта программа идёт с упором на сжатие видеоигр, скачанных из Steam, но для остального она подходит не очень хорошо. Принцип работы — выбираешь папку, один из четырёх алгоритмов, смотришь прогноз сжатия (если для какой‑то игры есть такая информация), и если всё устраивает — то делаешь сжатие.
В бета‑версии 4.0 добавили более приятный интерфейс и ускорили проверку, но основные фичи остались такими же:
Увеличенная база данных от сообщества с результатами сжатия тысяч игр, чтобы проще оценивать, как хорошо примерно сожмутся игры, если данные не устаревшие. Но этот прогноз действует только для игр из Steam или EGS — если же игра находится не в Steam, или же это вовсе не игра — то прогноза сжимаемости не будет, и придётся сжимать файлы вслепую. Из‑за этого не рекомендуется сжимать более одной программы или несколько игр одновременно.
Background Watcher — служба в фоне, которая следит за папками, видит обновление игры и автоматически сжимает файлы заново, когда компьютер простаивает.
Настраиваемые списки плохосжимаемых расширений.
CompactGUI отдельно предупреждает о том, что не рекомедуется сжимать игры, поддерживающие DirectStorage API — сжатие может испортить выигрыш от прямой загрузки в GPU.
Другая программа, Compactor, написана на Rust, и до момента выхода CompactGUI бета‑версии 4.0, была самой быстрой из таких программ. У нее всё ещё есть преимущество в виде пропуска уже сжатых файлов и меньшего использования ОЗУ, но разница составляет лишь пару сотен мегабайт в памяти при сканировании огромных папок. В ней тоже есть примитивная фильтрация в виде простой хэш‑базы с кэшем уже проверенных несжимаемых файлов, чтобы повторные запуски по той же папке проходили быстрее.
У обоих инструментов есть общие недостатки.
Нет предварительной оценки сжимаемости файлов, и никак не опознаются плохо сжимаемые файлы, если они постоянно заменяются — а в условиях повсеместно встречающихся программ на Electron, с кэшами по пару гигабайт каждая, это происходит гарантированно.
В этих программах можно только взять одну папку, выбрать один алгоритм на всю папку, и сжать всё подряд одним алгоритмом. Но в зависимости от размера файла и от мощности компьютера, использовать лучше всего только определённые алгоритмы. LZX — не панацея.
Нет кнопки типа «нажал и забыл».
Пользователю с ходу не понять, какой алгоритм и для чего использовать — потянет ли его слабый новый игровой ноутбук алгоритм XPRESS4K, или мощнейший бюджетный китайбук на Intel Celeron алгоритм LZX. Это должна выбирать сама программа.
Поэтому я однажды решил создать пет‑проект, который эти все принципы осуществляет, чтобы как сисадмину иметь возможность выбрать определённые директории, без разбора сжать всё что надо, и выполнить это сразу на десятках компьютеров. Это всё началось с возможности подбирать алгоритмы, но потом постепенно углубляясь в эту сферу, масштаб увеличивался и добавлялось всё больше и больше фич. Под конец всё оказалась таким хорошим, что удалось создать такую программу, которая превосходит всё, что существовало до этого.
Делаем это
trash‑compactor (прямая ссылка для скачивания здесь, плюс если не работает первая ссылка) имеет два режима работы:
Графический интерфейс для рядовых пользователей ПК
Консольный интерфейс, чтобы различным сисадминам можно было создавать задачи с Планировщиком Задач в Windows или скрипты, которым надо запустить программу на большом парке компьютеров на Windows
Однако 99% пользователям понадобится лишь графический интерфейс, чтобы один раз в полгода нажать на кнопку для сжатия программ и игр, и забыть.
В графическом интерфейсе, можно выбрать два пути:
Быстро сжать файлы в часто используемых папки, таких как Program Files, AppData и Downloads, а также сжать файлы Windows через функцию CompactOS, встроенную в саму Windows, чтобы системная папка Windows занимала в среднем на 30–40% меньше места на диске.
Выбрать свою папку для сжатия. Можно сжимать как на системном томе, так и на сторонних дисках — главное, чтобы файловая система была NTFS, а не exFAT и тому подобное
Во всех случаях, ни один файл не удаляется с диска, и не изменяется на уровне самого файла. При копировании сжатых папок в другое место, будь то на флешку или на другой компьютер, копия этого файла на другом носителе будет в разжатом состоянии — следовательно, можно на диске 256ГБ хранить де юро 320ГБ информации.
Не все файлы хорошо сжимаются. Плохо сжимаются:
архивы, фото, видео, аудио, и прочие файлы, которые сами по себе являются сжатыми;
документы для Word, Excel, PowerPoint в форматах
docx,xlsx,pptx,pdf‑документы и прочие документы, которые сами по себе находятся в сжатом состоянии;пакеты
gguf,safetensors,torchи другие пакеты для машинного обучения и ИИ;образы для виртуальных машин (они полностью разожмутся, как только произойдёт запись данных в образ);
файлы различных необычных форматов (в том числе установленные игры), сами по себе являющимися сжатыми данными.
Для распознавания всех таких файлов, в программе реализован инструментарий анализа папок. Он основан на проверке расширений файлов. А когда списка расширений, связанных с плохо сжимаемыми файлами, начинает нехватать — в бой идёт проверка энтропии Шэннона у файлов, в рамках которой часть файлов предварительно сжимается в нескольких случайных местах (не целиком) через самые быстрые алгоритмы сжатия, без какой‑либо записи информации на диск, чтобы не изнашивать SSD. Этой продвинутой и быстрой проверкой (которой нет у аналогов) точно определяется процент сжимаемости файлов, и если он хорошо сожмётся — то его можно будет сжать подходящим алгоритмом, если запустить сжатие.
Как это выглядит на практике:
Благодаря этой многогранной автоматизации, нет необходимости гадать, как хорошо сожмётся папка, не нужно тратить время на сжатие разных папок или игр по отдельности, или на добавление плохо расширяемых файлов. Сжать может даже неуверенный пользователь ПК. Есть даже отдельная проверка мощности компьютера — если компьютер слабый или старый, то будут использоваться только лёгкие способы сжатия, чтобы он не становился медленнее от сжатия программ или игр.
Если позволить себе немного пафосности, эта программа — самый близкий аналог тех программ, из 90-х и 2000-х, которые нажатием одной кнопки «скачивали больше оперативной памяти», однако тут всё происходит наяву, и подвохов нет — потому что исходный код программы полностью открыт.
Подноготная (кому очень интересно)
Обход и классификацию файлов выполняет созданное поддельным интеллектом (единственно правильный подход для бесплатных малоизвестных пет‑проектов) расширение «fast_walk», прикрученное к питоновскому проекту, написанное на Rust с использованием PyO3 и rayon. При сборке модуль собирается в wheel и встраивается в исполняемый файл. Многопоточное сканирование применяет фильтры расширений, определяет подходящий алгоритм сжатия в зависимости от размера файла, проверяет атрибуты NTFS через GetFileAttributes чтобы определить и не сжимать уже сжатые файлы.
После предварительного сканирования, в каждой директории выбирается ~50 файлов; для каждого читает динамическое число окон по 16 КБ. Позиции окон для сжатия выбраны так, чтобы избегать заголовков и футеров у файлов, где хранятся несжатые данные, и было значительно меньше ложноположительных результатов анализа. Для оценки плохо сжимаемых файлов, используется самый лёгкий алгоритм LZ4, для быстрого отсеивания несжимаемых фалйов. Если они сжимаются, то эти окна файлов сжимаются второй раз алгоритмом ZLIB уровня 2. После этого, подсчитывается средняя статистика сжатия файлов в директории. Если значение ниже порога в 15% (можно менять в настройках), то эта директория целиком пропускается, и файлы кэшируются как плохо сжимаемая по xxhash64 полного пути в incompressible.db.
На практике, это с точностью выше 95% позволяет отфильтровать директории, где находятся кэши программ, где под капотом используется Electron — эти кэши составляют по несколько гигабайт у каждой программы, и из примеров таких программ — любые браузеры, программы Discord, Telegram, Slack, Microsoft Teams, Visual Studio, VSCode, Cursor, Notion, Figma, WhatsApp, Obsidian, Spotify, 1Password, Postman, Docker Desktop, Beekeeper Studio, GitHub Desktop, Trello, Joplin, Twitch Desktop... В общем, вы поняли, откуда ноги растут, и что произойдёт, если вслепую пытаться сжать то, что совершенно не сжимается и постоянно меняется.
При сжатии, Windows 10 и 11 дают возможность сжать файлы такими алгоритмами, которые программа выбирает самостоятельно:
XPRESS4K (наиболее лёгкий)
XPRESS8K
XPRESS16K
LZX (наиболее мощный и тяжёлый)
Для файлов размером <64 КБ — XPRESS4K, <256 КБ — XPRESS8K, <1 МБ — XPRESS16K, выше — LZX по умолчанию, кроме случаев, когда компьютер оказывается слишком слабым.
LZX — словарный алгоритм на базе LZ77 с Huffman‑кодированием, который использует больший эффективный словарь, чем XPRESS с окнами 4/8/16 КБ, Он даёт более высокие коэффициенты на исполняемых файлах, DLL и ресурсах, и он умеет сжимать то, что может очень плохо сжиматься алгоритмами XPRESS.
Но LZX не подойдёт для слабых компьютеров, имеющих плохую производительность в однопотоке. Мощность компьютера автоматически проверяется на старте в однопоточном бенчмарке производительности, где симулируется декомпрессия. Если компьютер не укладывается в 0.25 секунд, то он недостоин использовать LZX, и везде будут использоваться алгоритмы XPRESS. Xeon'щикам не о чем беспокоиться — несмотря на множество ядер, их процессоры гарантированно провалят этот тест.
