lolz test22c4b

[Edison007]

Правильно ли будет сказать, что если архив создан с ключом (-mtt0), то при распаковке lolz будет потреблять память не бесконтрольно, а отталкиваясь от значения словаря (-d), которое было задано при компрессии.
Например ели словарь был равен (-d208), то расход памяти при распаковке + погрешность, будет отталкиваться от этого значения?

Зависит от кол-ва потоков при упаковке (повторюсь, при mtt0 для распаковки используется столько же потоков, сколько и при упаковке), точнее будет (dN+mtbN+хвосты)*mtN

Размер словаря 16 мб., который приведён в примере - это параметр (-d), который задаётся при компрессии, ведь так?!

yep

В CLS.ini в строке MaxThreadsUsage=50%, возможен ли вот такой вид?:
MaxThreadsUsage=50p-1

Ох, а вот этого я не помню, слишком давно я уже не делаю репаков, да и не использовал никогда многопоточность LOLZ, только в тестах, придется вам самим тестировать этот момент

 

[Den.Scaletta]

Зависит от кол-ва потоков при упаковке (повторюсь, при mtt0 для распаковки используется столько же потоков, сколько и при упаковке), точнее будет (dN+mtbN+хвосты)*mtN


yep


Ох, а вот этого я не помню, слишком давно я уже не делаю репаков, да и не использовал никогда многопоточность LOLZ, только в тестах, придется вам самим тестировать этот момент

Edison007, благодарю вас.
Значение взято из параметров запуска xtool.

Спойлер: Arc.ini:

[External compressor:xtool]
header = 0
packcmd   = xtool.exe precomp { -option} -d1 -mpng -mzlib -mpreflate -c32mb -t90p-1 --mem=90p --dbase --dedup - - <stdin> <stdout>

Также в CLS.ini для параметра MaxMemoryUsage=50%, возможно написание вида: MaxMemoryUsage=50%-50m.
Замена знака (%) на букву (p) и вычитание одного ядра, допустимо в xtool.
Потому и предположил, что и для lolz что-то такое возможно.
Буду проверять.
Проверил последовательную распаковку, xtool+lolz, через inno setup, без подключения библиотеки cls-lolz.dll и с добавлением записи в arc.ini:

Спойлер: Arc.ini:

[External compressor:lolz]
header = 0
unpackcmd = cls-lolz_x64.exe $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

Расход памяти намного меньше т.к. xtool и lolz отрабатывают по очереди.
В таком варианте, может быть, возможно попробовать оставить архив с ключом (-mtt0), вдруг отработает без ошибки unarc -12.
Но заметил один неприятный момент.
В директории игры, куда идёт распаковка, создаётся папка temp с приличным весом и после закрытия инсталлятора, она не удаляется. В случае с включенной cls-lolz.dll, всё благополучно удаляется.
Вы с таким не сталкивались?

 

[Edison007]

Расход памяти намного меньше т.к. xtool и lolz отрабатывают по очереди.

И установка дольше

Вы с таким не сталкивались?

Сталкивался, но при других вводных, но сути это не меняет. Решалось так: в папке куда ставится приложение создаётся папка "FA_TEMP" (У меня так называлась, можно любое другое название придумать), и эта папка назначалась, как "рабочая" во всех функциях распаковки, в конце установки удаляем папку, PROFIT! )

 

[Den.Scaletta]

И установка дольше



Сталкивался, но при других вводных, но сути это не меняет. Решалось так: в папке куда ставится приложение создаётся папка "FA_TEMP" (У меня так называлась, можно любое другое название придумать), и эта папка назначалась, как "рабочая" во всех функциях распаковки, в конце установки удаляем папку, PROFIT! )

Edison007, здравствуйте.

Файл 2.18 гб. с ключами (-mtt0 -mt1 -d208m -mtb104m)(после распаковки 7.47 гб.) на стадии распаковки lolz обрабатывает за 6 минут.

Спойлер: При таком расходе памяти:

Потом его сменяет xtool и отрабатывает за 3 минуты.

Спойлер: С такими параметрами:

[External compressor:xtool]
header = 0
unpackcmd = xtool.exe decode -t100p-1 --mem=25p --dedup - - <stdin> <stdout>

Спойлер: И таким расходом памяти:

Ошибка unarc.dll -12, происходит именно на стадии распаковки xtool. Приходится играть с ключом (--mem).
По умолчанию этот ключ равен --mem75p
На своей системе пришёл к таким значениям (-t100p-1 --mem=25p).
В сумме всё время распаковки равно 9 минутам.
С активной cls-lolz.dll время распаковки равно 7 минутам.
Вы были правы.

В папке куда идёт распаковка создаётся вот такая папка с таким содержимым:

Спойлер: :

По завершении распаковки в директории остаётся вот такая папка с таким содержимым:

Спойлер: :

Если вас не затруднит подскажите пожалуйста наглядным примером как можно реализовать удаление этой папки.
Также заметил что на стадии распаковки lolz, проценты строки прогресса не активны.

Спойлер: :

Только когда xtool сменяет lolz, начинается отсчёт процентов.
Это можно как-то исправить?

 

[Edison007]

Если вас не затруднит подскажите пожалуйста наглядным примером как можно реализовать удаление этой папки.

Именно эту папку удалить будет проблематично, ибо unarc.dll выдаёт случайное название каждый раз, поэтому я писал, что для этого нужно создать папку FA_TEMP, и использовать её как "рабочую"

Крч:
1. где-нибудь перед распаковкой архивов (можно сразу после ISDoneInit), вставить это: ForceDirectories(ExpandConstant('{app}\FA_TEMP')); // создаём папку
2. в функциях ISArcExtract, предпоследний параметр меняем на (ОБЯЗАТЕЛЬНО!) ExpandConstant('{app}\FA_TEMP')
3. после распаковки архивов вставляем это: if DirExists(ExpandConstant('{app}\FA_TEMP')) then DelTree( ExpandConstant('{app}\FA_TEMP'), True, True, True); // удаляем папку с временными файлами

Это можно как-то исправить?

"Адекватными" методами нет) И стоит еще заметить, что для установки потребуется дополнительные 7 ГБ свободного места на харде
Вообще, мне кажется, что косячит именно xtool в данном случае, ибо общее потребление памяти ~ 1,2гб, и на системе с 4 ГБ ОЗУ всё должно быть норм. Или же, как ни раз говорили, что-то глючит в stdin-out.

 

[dixen18]

@Den.Scaletta, Вроде как параметр --mem=25p используется при условии если во время упаковки был активен параметр --dedup.
Это ограничение введено после того как выяснилось что дедупликация при распаковке сжирает немерянное количество ОЗУ и XTOOL просто прекращал работу. А это -известная ошибка decompression falls.
Лично я дедупликацию не использую совсем. Зачем оно надо если есть SREP?))

 

[Den.Scaletta]

Именно эту папку удалить будет проблематично, ибо unarc.dll выдаёт случайное название каждый раз, поэтому я писал, что для этого нужно создать папку FA_TEMP, и использовать её как "рабочую"

Крч:
1. где-нибудь перед распаковкой архивов (можно сразу после ISDoneInit), вставить это: ForceDirectories(ExpandConstant('{app}\FA_TEMP')); // создаём папку
2. в функциях ISArcExtract, предпоследний параметр меняем на (ОБЯЗАТЕЛЬНО!) ExpandConstant('{app}\FA_TEMP')
3. после распаковки архивов вставляем это: if DirExists(ExpandConstant('{app}\FA_TEMP')) then DelTree( ExpandConstant('{app}\FA_TEMP'), True, True, True); // удаляем папку с временными файлами


"Адекватными" методами нет) И стоит еще заметить, что для установки потребуется дополнительные 7 ГБ свободного места на харде
Вообще, мне кажется, что косячит именно xtool в данном случае, ибо общее потребление памяти ~ 1,2гб, и на системе с 4 ГБ ОЗУ всё должно быть норм. Или же, как ни раз говорили, что-то глючит в stdin-out.

Edison007, всё исполнил и всё сработало - это потрясающе!
Очень вам благодарен за эти знания!

А то что нужно доп. место, то да.
Хотя при обработке xtool, там всё равно создаётся файл на период распаковки, но много меньше. Потом правда сам удаляется:

Спойлер: TEMP:

Заметил ещё кое-что.
Хоть это и очевидно, но всё же скажу об этом.
Xtool и Lolz(с ключами -mtt0 -mt1) выставляют расход памяти для себя отталкиваясь от текущего физического
объёма озу.
Вот тест на 8192 озу:

Спойлер: 8192:

А вот тест на 2048 озу:

Спойлер: 2048:

Исходя из этого предположил что при грамотной настройке поведения xtool, есть возможность оставить в паре при
включенной cls-lolz.dll, лолз-архив созданный с ключами (-mtt0 -mt1).
И да, всё работает и ошибка unarc.dll -12, не возникает.
Я очень рад этому.
Осталось проверить на другой системе с ноутбука.
Был случай, когда были подогнаны значения на моём системнике к 2048 озу и ошибка не возникала.
Но когда, запустил инсталлятор на ноутбуке с 4096 озу, ошибка появилась.
Другая система потёмки.
И всё же очень хочу узнать как решается фриз с процентами при распаковке без cls-lolz.dll.

 

[Edison007]

Вроде как параметр --mem=25p используется при условии если во время упаковки был активен параметр --dedup.

Кстати, да, довольно важное замечание)

Зачем оно надо если есть SREP?))

Вот тут не соглашусь, дедупликация выдаст итоговый результат сжатия лучше, чем связка с SREP. К тому же дедупликация и SREP могут дополнять друг друга

Хотя при обработке xtool, там всё равно создаётся файл на период распаковки, но много меньше.

Это скорее всего и есть файл с дубликатами. Сам я не тестил xtool, т.ч просто предположение.

Заметил ещё кое-что.

Наверняка замеры сделаны в разные моменты распаковки, ибо lolz на любой системе будет жрать одинаковое кол-во памяти на поток. (Невозможно распаковать данные выделив меньше ОЗУ для словаря + размер блока)

И всё же очень хочу узнать как решается фриз с процентами при распаковке без cls-lolz.dll.

unarc.exe + функция IsExec, но прогресс будет очень примерный, возможно может помочь ручная расстановка процентов (читай в справке), но сомневаюсь

 

[Den.Scaletta]

@Den.Scaletta, Вроде как параметр --mem=25p используется при условии если во время упаковки был активен параметр --dedup.
Это ограничение введено после того как выяснилось что дедупликация при распаковке сжирает немерянное количество ОЗУ и XTOOL просто прекращал работу. А это -известная ошибка decompression falls.
Лично я дедупликацию не использую совсем. Зачем оно надо если есть SREP?))

dixen18, здравствуйте!
Возьму на заметку ваши слова.

Почему я начал использовать ключ --dedup в xtool.
Наверняка вы всё это прекрасно и без меня знаете, но всё же скажу.
Вот для примера папка с файлами в которых zlib компрессия, весом 1.03 ГБ.
После прохода с ключом --dedup, вес архива на выходе равен 204 МБ., который lolz сжимал до 50% ровно 7 минут.
После прохода без ключа --dedup, вес архива на выходе равен 1.58 ГБ., который lolz сжимал до 50% ровно 49 минут.
Что лучше?

Также, провёл тесты с ключом --mem.
Выяснилось что для моей системы допустимы следующие значения:
Допустимые значения для 2 гб. озу (--mem=25p --mem=35p --mem=45p --mem=55p)
Не допустимые значения при 2 гб. озу (--mem=65p --mem=75p(по умолчанию) --mem=85p --mem=95p) - эти значения у меня приводили к ошибке.
Вот два теста с разным объёмом озу и активным ключом --dedup.
Вот тест на 8192 озу:

Спойлер: 8192:

А вот тест на 2048 озу:

Спойлер: 2048:

Версия Xtool v0.5.3.
Версия Lolz v22c4b.
В данном случае главное настроить поведение Xtool.

Ну и последнее, стараюсь не использовать srep.
В цепи xtool+srep+lolz, архив на выходе получается больше чем если, xtool+lolz.
Функция LDMF в lolz прекрасно отрабатывает вместо srep и архив на выходе, меньше.
Но тут наверно, каждому своё!
Я пришёл к этому, кто-то придёт к другому.
Удачи!

 

[Den.Scaletta]

Наверняка замеры сделаны в разные моменты распаковки, ибо lolz на любой системе будет жрать одинаковое кол-во памяти на поток. (Невозможно распаковать данные выделив меньше ОЗУ для словаря + размер блока)

Edison007, замеры снимались на 95% распаковки. Все условия включая параметры запуска для xtool, одинаковы.
В системе только убавил озу, больше ничего не трогал. Lolz в обоих случаях распаковывал архив созданный с ключами (-mtt0 -mt1)
И да, я понимаю что при распаковке идет накопительный момент в озу до определенного потолка, поэтому и поставил на этом акцент.

unarc.exe + функция IsExec, но прогресс будет очень примерный, возможно может помочь ручная расстановка процентов (читай в справке), но сомневаюсь

Попробую разобраться, хотя очень смутно представляю как к этому прийти.
Edison007, большое спасибо за ваши знания и дельные рекомендации.
Берегите себя и будьте здоровы!

 

[Edison007]

замеры снимались на 95% распаковки. Все условия включая параметры запуска для xtool, одинаковы.

Интереснo, а swap-файл в системе имеется? Может часть данных в него скидывается?

 

[Den.Scaletta]

Интересна, а swap-файл в системе имеется? Может часть данных в него скидывается?

Edison007, выставлен на контроль от ос.

Спойлер: Swap

Но как я понял, возможно ошибочно, возможно нет, но при распаковке учитывается только физически возможная озу без учёта виртуальной подкачки.
Потому как, даже при ручной установке файла подкачки в значение 16384 ГБ, ошибка всё равно появлялась.

 

[dixen18]

По поводу ненужности SREP не согласен.
Одно дело жать одну игру меньше 10 гб и другое - каждый день ужимать игры под 40-60 гигов. И у каждой свои капризы

 

[Den.Scaletta]

По поводу ненужности SREP не согласен.
Одно дело жать одну игру меньше 10 гб и другое - каждый день ужимать игры под 40-60 гигов. И у каждой свои капризы

dixen18, видимо так и есть!
Я не знаком с подобным алгоритмом действий. Мой алгоритм начался на размере 7.47 ГБ., на нём и провожу тесты и пытаюсь добиться максимальной компрессии.
Да и разница если честно, когда участвует srep в цепи и когда не участвует, очень незначительная.

 

[Den.Scaletta]

Edison007, здравствуйте.

Сегодня провел последний, я надеюсь, тест, на другой системе, где возникала ошибка unarc.dll -12.
Это ноутбук с windows 8.1 и 4096 озу. Предварительно протестировав на своей с 2048 озу. Потому как, был случай, когда
после моих 2048 выдавало ошибку на 4096.
Параметры запуска:

Спойлер: Xtool:

Параметры прекомпрессии с которыми был собран архив:

[External compressor:xtool]
header = 0
packcmd   = xtool.exe precomp { -option} -d1 -mpng -mzlib -mpreflate -c32mb -t100p-1 --mem=100p --dbase --dedup - - <stdin> <stdout>

Параметры распаковки:

[External compressor:xtool]
header = 0
unpackcmd = xtool.exe decode -t100p-1 --mem=25p --dedup - - <stdin> <stdout>

Пробовал вначале со значением --mem=55p:

[External compressor:xtool]
header = 0
unpackcmd = xtool.exe decode -t100p-1 --mem=55p --dedup - - <stdin> <stdout>

Благополучно получая ошибку.

Спойлер: Lolz:

Архив был собран с данными ключами:

[External compressor:lolz]
header = 0
packcmd = lolz_x64.exe -d204m -mtb108 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

Вес архива 2.18 ГБ, после распаковки 7.47 ГБ.
Параллельная распаковка xtool+lolz, происходит 8 минут при активной cls-lolz.dll.

Чтобы с уверенностью сказать что (--mem=25p) - это лучшее стартовое значение для 2048 и выше, которое гарантированно избавит от ошибки unarc.dll -12, нужно протестировать значение (--mem=25p) ещё как минимум на двух системах с соответствующими характеристиками.

Once is happenstance. Twice is coincidence. Three times is enemy action.

Удачи.

 

[Edison007]

Вес архива 2.18 ГБ, после распаковки 7.47 ГБ.

А залей эти данные на какое-нибудь облако, у себя посмотрю, что может хтулу не нравиться

 

[Den.Scaletta]

А залей эти данные на какое-нибудь облако, у себя посмотрю, что может хтулу не нравиться

Edison007, чуть позже, сделаю.

 

[Den.Scaletta]

Edison007, сегодня пришла такая мысль, пока с этим возился.
Я конечно не программер, чтобы Рэйзору отписать свои наблюдения, да и вдруг они ошибочны.
Но почему бы для значения (--mem) не реализовать режим (--mem=auto), который будет высчитывать общую и свободную озу без учёта свопа. И отталкиваясь от результата сканирования, выставлять рекомендуемый шаблон для текущей ос.
Понимаю, что это куча работы, но результат того стоит.

 

[dixen18]

@Den.Scaletta, Вы можете написать о своих наблюдениях / предложениях в ветке XTool на fileforums. Единственное что..надо писать только на английском тк. правила форума + разор по-русски читать не умеет а такие специализированные темы переводить через машинные переводчики - такое себе занятие
И кстати а почему Вы в параметре --dedup не указываете имя файла куда скидываются записи о дубликации? --dedup=myfile.xtl например

 

[Den.Scaletta]

@Den.Scaletta, Вы можете написать о своих наблюдениях / предложениях в ветке XTool на fileforums. Единственное что..надо писать только на английском тк. правила форума + разор по-русски читать не умеет а такие специализированные темы переводить через машинные переводчики - такое себе занятие
И кстати а почему Вы в параметре --dedup не указываете имя файла куда скидываются записи о дубликации? --dedup=myfile.xtl например

dixen18, здравствуйте.

Попробую обдумать и сформулировать без лишнего свои наблюдения для Рэйзора.

Вначале использовал этот вид ключа --dedup и об этом отписался вот здесь:

Спойлер: Обязательные условия ключа --dedup:

XTool (2020)

Mickey1s обновил(а) ресурс XTool (2020) новой записью: 0.4.7 Update available Changes - updated oodle scanner - updated external executable support - updated configuration based plugin support to add depth information - updated verbose mode Notes Given that very small number of people are...

krinkels.org

Позже, столкнулся с ситуацией и провёл наблюдения, которые описал там же чуть ниже:

Спойлер: Лучший вариант написания ключа --dedup:

XTool (2020)

Mickey1s обновил(а) ресурс XTool (2020) новой записью: 0.4.7 Update available Changes - updated oodle scanner - updated external executable support - updated configuration based plugin support to add depth information - updated verbose mode Notes Given that very small number of people are...

krinkels.org

Начиная с версии xtool v0.3.21 по v0.6.0, ключ --dedup может работать как в таком виде --dedup=xtool.bin так и в таком виде --dedup.
Для версии xtool v0.3.9 чтобы на выходе получить меньший файл, нужно было обязательно наличие вида --dedup=xtool.bin.
Если попробовать поставить для этой версии вид --dedup, то:
Папка весом 1.03 ГБ после прекомпрессии будет весить 1.57 ГБ.
А если поставить вид --dedup=xtool.bin, тогда:
Папка весом 1.03 ГБ после прекомпрессии будет весить 205 МБ. и для неё будет создан файл xtool.bin.

Дело в том, если у вас в проекте участвует, допустим две папки, которые пройдут прекопрессию с --dedup=xtool.bin.
То для каждого из получившихся архивов, нужен будет свой xtool.bin.
Если после прекомпрессии первой папки и создания первого xtool.bin, провести прекомпрессию второй папки, xtool.bin, который был создан при прекомпрессии первой папки, не удалится, а дополнится информацией о втором проходе. Что в дальнейшем, при распаковке, приведёт к ошибке.
При распаковке, в директории где находится xtool.exe, должны находится оба варианта xtool.bin, типа: xtool-1.bin, xtool-2.bin.
Но подобное переименование не принимается программой.
Поэтому, теперь, использую только вид --dedup, разницы никакой нет.
Можете проверить всё сами, скачав вот отсюда:

Спойлер: Архив версий xtool от Рэйзора:

1.28 GB folder on MEGA

172 files and 36 subfolders

mega.nz

xtool v0.3.9 и прогнав с обоими видами, какую-нибудь папку.
А потом прогнать то же через xtool v0.3.21, xtool v0.5.3 или xtool v0.6.0.

P.S. Расширение XTL, которое приведено в вашем примере, используется для обозначения файла database и применяется при прекомпрессии в ключе --dbase(например --dbase=fc3.xtl) если есть соответствующий файл database.
В ключе --dedup, если обозначается вид типа, xtool.bin, расширение может быть разным, но я всегда использовал как сказано в справке, расширение xtool.bin.
P.P.S. Я до сих пор не умею создавать дата-базу(наверно ленюсь ) и никто не хочет подсказать как.