Что за процесс lzma2.exe?Зачем он ?
Это специальная утилита, которую используют различные установщики. Обычно она есть память пропорционально объёму сжатого файла.
Похожие вопросы
Ваш браузер устарел
Мы постоянно добавляем новый функционал в основной интерфейс проекта. К сожалению, старые браузеры не в состоянии качественно работать с современными программными продуктами. Для корректной работы используйте последние версии браузеров Chrome, Mozilla Firefox, Opera, Microsoft Edge или установите браузер Atom.
7-Zip 9.03 Alpha — новая версия архиватора с поддержкой LZMA2
Вышла очередная тестовая версия свободного, отечественного архиватора 7-Zip под номером 9.03. Программа использует свой собственный алгоритм для упаковки в формат 7Z с высокой степенью сжатия. Помимо этого, может упаковывать в форматы ZIP, GZIP, BZIP2, TAR и извлекать из ZIP, CAB, RAR, ARJ, LZH, GZIP, BZIP2, Z, TAR, CPIO, RPM, DEB архивов.
Менеджер файлов не может похвастаться значительной функциональностью и удобством, зато поддерживается интеграция в контекстные меню, так что упаковка и извлечение файлов не потребует большого количества манипуляций.
Распространяется свободно, с открытыми исходными кодами, а его алгоритм формата для 7z применяется в других, как коммерческих (PowerArchiver), так и бесплатных архиваторах (TUGZip). 7-Zip, наверное, является единственной программой подобного рода, которая переведена на огромное количество языков, в том числе и экзотические.
На данный момент реализована поддержка метода сжатия LZMA2 (позволяет в полной мере задействовать ресурсы многоядерных систем), реализована возможность работы с архивами формата XZ, добавлены средства для извлечения данных из архивов разделов с файловыми системами NTFS, FAT, образов VHD и загрузочных секторов MBR, а также расширена работа с архивами GZip, BZip2, LZMA, XZ и TAR. Кроме того, улучшена работа файлового менеджера, добавлены новые ключи для работы из командной строки, а также исправлены мелкие недоработки. В этом выпуске исправлены мелкие ошибки, а также улучшена система обновления архивов формата 7z.
Основные характеристики 7-Zip:
Поддерживаемые форматы:
Полностью: 7z, ZIP (кроме WinZip 11 версии), gzip, bzip2, tar.
Частично (только распаковка и просмотр): CAB, RAR, ARJ[2], cpio, RPM, deb, (ar), Z, LZH, Compiled HTMLHelp, SPLIT, Windows Installer, NSIS Installer.
Очень высокая степень сжатия в новом формате 7z благодаря использованию усовершенствованного алгоритма Лемпела-Зива.
Для форматов ZIP и GZIP степень сжатия на 2—10 % выше, чем у PKZip и WinZip.
Возможность создания самораспаковывающихся архивов для формата 7z.
В формате 7z возможно создавать многотомные архивы (в наст. время за исключением самораспаковывающихся)
Возможность шифрования архивов, алгоритмом AES с длиной ключа 256 бит (для формата 7z).
Интеграция в оболочку Microsoft Windows и Windows NT.
Плагин для программы FAR Manager.
Плагин для программ Total Commander и Unreal Commander.
Мультиязычный графический интерфейс (только для Windows) с функциями двухоконного файлового менеджера.
Мощная версия для командной строки.
Существует версия для 32 разрядных и 64 разрядных систем.
Порт под *nix p7zip
Что такое файл LZMA?
Файл с LZMA расширением файла является файл LZMA Сжатый. Суффикс обозначает цепной алгоритм Лемпеля-Зива-Маркова, а файлы в основном видны в операционных системах на основе Unix .
Файлы LZMA аналогичны другим алгоритмам сжатия, таким как ZIP, которые сжимают данные для экономии места на диске . Однако сжатие LZMA, как известно, обеспечивает более быстрое время распаковки, чем другие алгоритмы, такие как BZIP2.
LZMA2 — это контейнерный формат, который может содержать как данные LZMA, так и несжатые данные. Ниже приведена дополнительная информация об их различиях.
TLZ — это сокращение от файла TAR , сжатого с помощью LZMA. Он использует расширение файла TAR.LZMA и обычно называется сжатым тарболом LZMA.
Как открыть файл LZMA
PeaZip и 7-Zip — две бесплатные программы для Windows и Linux, которые могут распаковывать (извлекать) содержимое файла LZMA. Unarchiver может открывать файлы LZMA на Mac, а B1 Free Archiver является аналогичным средством открытия файлов LZMA для Windows, Linux, macOS и Android.
Чтобы открыть файл TAR, который спрятан в архиве LZMA, может потребоваться два шага: извлечь файл TAR из LZMA и затем распаковать данные из файла TAR. Некоторые программы декомпрессии объединяют эти шаги в один, делая процесс немного легче.
В терминале Unix вы можете увидеть этот двухэтапный процесс при выполнении одной команды . Данные в файле TAR можно распаковать из архива LZMA с помощью следующей команды (замените файл file.tar.lzma своим собственным файлом LZMA):
Выбор способа сжатия ресурсов игры (lzma2, lzham, lzmh, lzo, lz4, snappy/yappy и т.д.)
Вопрос простой. Что выбрать? 🙂
И вообще, кто что использует?
Ещё пару-тройку лет назад можно было не заморачиваться и паковать всё deflate-ом в zip по старинке. А счас, я смотрю, такая куча алгоритмов нарисовалась/заопенсурсилась, что аж глаза разбегаются! 🙂
Ну, юзать zlib в настоящее время, как я понимаю, вообще не вариант. Старый архаичный код deflate, писавшийся ещё для 16-разрядных процессоров, уступает по всем параметрам (скорость сжатия/распаковки, степень сжатия) первому пришедшему в голову Deflate64.
Вообще, требуется найти 3 алгоритма для соответствующих типов данных (ресурсов):
1. Загружаемые по инету ресурсы (в т.ч. патчи для системы обновлений). Тут я выбрал lzma2. Думаю, больше альтернатив особо и нет.
2. Обычные ресурсы (в пак-файлах), загружаемые с диска. Требования: скорость распаковки, не медленнее скорости чтения HDD (т.е. минимум 70 Мб/с, а лучше 100 Мб/с, zlib даёт лишь 40-60 Мб/с, lzma — 10-30, но это ещё от типа данных зависит), т.е. чтобы данные могли на лету при чтении потоково распаковываться без перерывов, скорость компрессии: не принципиально, степень сжатия: не хуже zlib.
Лучший вариант — lzmh (декомпрессия в 4 раза быстрее lzma, в 2 раза быстрее lzham при степени сжатия, сопоставимой с lzma), но, к сожалению, этот алгоритм находится в каком-то подвешенном состоянии (непонятно, что с лицензией, и вообще, какова его стабильность и т.д.). Ещё неплох lzham, но опять же статус alpha смущает, да и скорость распаковки лишь немного превосходит zlib.
3. Ресурсы, загружаемые с диска (тоже из пак-файлов), но кешируемые в оперативной памяти и распаковываемые при необходимости. Требования: очень высокая скорость декомпрессии, скорость компрессии: не принципиально, степень сжатия: не высокая, но желательно на уровне lzo или lz4.
Варианты: lzf, lz4, snappy, yappy. Отдал бы предпочтение последнему, если бы было больше ясности, что там со стабильностью/требованиями алгоритма и, вообще, с развитием проекта (Петька, даёшь opensource-проектик в google.code! 🙂 )
#1
19:22, 19 июня 2011
Если интересует мое мнение, то я выбрал zlib, просто, доступно, и хорошее сжатие ( даже для передачи по сети данных ). Что еще нужно? А новые алгоритмы в мире сжатия придумать трудно, здесь прогресс может идти десятилетиями.
#2
20:16, 19 июня 2011
Принципиально новое конечно придумать трудно, но новых улучшений над известными старыми алгоритмами — полно. Зачем использовать алгоритм 15-летней давности, если есть куча его улучшенных версий, учитывающих современную архитектуру процессоров, а также объединяющие преимущества разных алгоритмов и использующие оригинальные подходы? Причем улучшения «старого» дают в результате увеличение скорости декомпрессии в несколько раз с такой же или даже большей степенью сжатия.
Лучшее — враг хорошего. 🙂
#3
1:03, 20 июня 2011
Жать вообще не надо. Ассеты надо собирать просто в один большой файл. Ресурсы собирают в один контейнер, чтобы не тормозило чтение кучи мелких файлов. Сжатие, как таковое, нужно только в исключительных случаях.
#4
3:09, 20 июня 2011
asfdfdfd
> Жать вообще не надо
Fail. Данные в пак фале нужно жать независимо, чтобы можно было прочитать ресурс и его расжать.
#5
9:17, 20 июня 2011
1. Можно ещё посмотреть bzip2 (pbzip2). На текстовых данных он жмёт лучше чем lzma, но распаковывает значительно медленнее.
2. Вменяемые конкуренты zlib — мне неизвестны.
3. Я не уверен в разумности хранения в памяти упакованных данных. Это дублирование дискового кэша операционной системы.
P.S. Упаковка ресурсов в один файл — это часто правильно.
#6
22:27, 20 июня 2011
asfdfdfd
> Ассеты надо собирать просто в один большой файл.
Это не противоречит сжатию. Я, например, сделал для startup-данных (файлы, которые всегда загружаются при каждом запуске игры) что-то вроде tarball или solid архива, т.е. это логически по-прежнему много маленьких файлов, которые получаются через loadFile в разных местах, но физически они объединены в один непрерывно сжатый пак-файл, который сначала читается-распаковывается в память, а затем, когда все файлы были прогружены и разложены по объектам/текстурам, память, выделенная под этот пак, освобождается целиком.
Во всех остальных паках, файлы сжаты по отдельности.
Вообще, сжатие оправдано всегда (с целью уменьшения времени загрузки ресурсов), вопрос лишь какое. В идеале, для каждого типа ресурсов нужно использовать свои алгоритмы, но на практике таким обычно никто сильно не заморачивается. DDS-текстуры, меши/модельки итак неплохо жмутся алгоритмами сжатия общего назначения.
nbkolchin
> Я не уверен в разумности хранения в памяти упакованных данных. Это дублирование дискового кэша операционной системы.
Дисковый кэш системы Windows — феноменальное УГ, да простят меня товарищи из Microsoft. Из-за по-дурацки реализованного копирования с частыми переходами kernel в user-mode и обратно (один переход в ядро — порядка 5-10 тыс. тактов) скорость чтения полностью закешированного файла не превышает 250 Мб/с, что уже сливает последним SSD.
Лучше читать файлы в обход такого кэша (с FLAG_NO_BUFFERING), и использовать свой файловый кэш, который даст практически мгновенный доступ к закешированным файлам. Единственный серьёзный минус (особенно во время разработки), что повторные запуски приложения будут так же медленны, как и первый.
Впрочем, виндовый кэш не сильно мешает, и читать файлы можно и через него. Но небольшой свой кэш на 64-128 Мб уже даёт ощутимый буст по сравнению с гигабайтным виндовым.
#7
23:17, 20 июня 2011
Расскажи про сжатие чувакам из ААА-тайтлов. 20 ГБ после установки? Фигня! 2 DVD диска на дистриб? Фигня!