» FreeArc (часть 4)

Цитата:

С ним то не распаковывается нифига.

ещё какая-то ошибка. если возвращать пароль через колбек, то работает:


Цитата:

C:\>UnarcDllExample.exe x hp12-old-scheme.arc
Password?12
password? 0 0 12
overwrite? 0 0 Arc.exe
filename 0 0 Arc.exe
read 0 0
read 0 0
read 0 0
read 0 0
write 3 0
write 3 0
quit 0 0
FreeArcExtract() was successful

выделенное жирным - это я с клавиатуры ввёл

ruduk
обычный алгоритм: чтение+поиск совпадений+запись

новый алгоритм:
1-й проход: чтение+поиск совпадений
2-й проход: чтение+запись

данные о совпадениях сохраняются в памяти между проходами и таким образом не ищутся на втором проходе. так что всё что мы теряем - память для хранения совпадений (1-10% от размера хеша) плюс повторное чтение данных, т.е. порядка 10 сек. на каждый гигабайт сжимаемых данных

Булат, а нельзя ли сделать опцию "Встроить SREP в SFX", чтобы не добавлять в сам ARC, я так понял это сложнее.

Bulat_Ziganshin

Цитата:

SREP 2.91 alpha

Великое событие!

Цитата:

"srep -f infile" performs 2-pass compression

первые ощущения: кажется оно быстрее в итоге работает, чем однопроходный.

Цитата:

The only way to limit memory usage at decompression is -mBYTES option - it will store in RAM only matches less than BYTES long. Other matches will be copied, as usual, directly from output file

реально именно этого и не хватало предыдущей версии срепа А этой теперь ограничения по используемой памяти для распаковки) Хоть это и не столь важно, ибо можно подогнать опцией -m.
З.Ы. интимный вопрос: почему альфы идут именно с циферкой *.91 ?

Добавлено:
Распаковываю 2.6гб srep-архив, в который упакованы 4 гб данных с параметрами -m3 -l32 -f. Пик памяти в срепе написано 525мб, в диспетчере задач показывает 700мб+ (потом постепенно уменьшается). Это из-за выделения кусочков оперативки кратной размеру страницы памяти в винде или фрагментации памяти?

да, с заданием пароля через каллбэк действительно все нормально распаковывает. Значит пасс надо будет не через параметр в FreeArcExtract передавать, а только в каллбэке прописывать передачу.

Bulat_Ziganshin

Цитата:

Matches 2123 3483 17796, memory 127mb 167mb 180mb

а при упаковке получитьэту информацию можно?

в идеале было бы хорошо если бы в SFX добавлялись внешние модули (SREP, precomp...) при необходимости

Цитата:

"srep infile.srep" decompress such file without additional I/O - all matches are stored in dictionary. Thus, it may decompress from stdin to stdout w/o tempfiles

вот засада, precomp всю картину портит

Добавлено:
у arc тоже нет stdin to stdout

у меня все время ошибка когда я запускаю UnarcDllExample.exe x archive.arc

а почему арк спрашивает ввод пароля (при открытии) когда исп-ся -dm<crypt_method> (при упаковке)?
кстати если скомбинировать -dm и -ae то будет ошибка


Цитата:

C:\unarc>arc a -dmaes-256 -p? -ae=aes-256 arc_ *
FreeArc 0.67 (September 10 2011) creating archive: arc_.arc

Enter encryption password:
Reenter encryption password:
Compressed 5 files, 555,392 => 345,688 bytes. Ratio 62.2%
Compression time: cpu 0.27 secs, real 0.27 secs. Speed 2,091 kB/s
All OK

C:\unarc>arc lt arc_.arc
FreeArc 0.67 (September 10 2011) listing archive: arc_.arc

Enter decryption password:
arc: aes-256/ctr:n1000:r0 doesn't include salt

C:\unarc>

или это не верное так делать ?

Bulat_Ziganshin
немного статистики распаковки

srep32i.exe -m3f xcmd.TAR.pcf xcmd.TAR.pcf.srep

copy xcmd.TAR.pcf.srep nul

srep32i.exe -d xcmd.TAR.pcf.srep nul
Compression ratio: 3482909069 -> 546455948: 15.69%. Cpu 132.210 mb/sec, real 126.166 mb/sec. Matches 0 109025 1771881, memory 0mb 101mb 1096mb

copy xcmd.TAR.pcf.srep nul

srep32i.exe -d -nomd5 xcmd.TAR.pcf.srep nul
Compression ratio: 3482909069 -> 546455948: 15.69%. Cpu 310.454 mb/sec, real 273.881 mb/sec. Matches 0 109025 1771881, memory 0mb 101mb 1096mb

объясните, пожалуйста, как использовать внешний упаковщик, в частности packjpg
в arc.ini ничего не трогал, файл оригинальный
packjpg.exe сложил в папку с arc.exe (path на эту папку прописан)
пробовал методы 5p и 9p - эффекта нет (

в arc.ini ещё указан некий timer (пробовал убрать, не помогло)
packcmd = timer packjpg $$arcdatafile$$.jpg
где взять его?

Цитата:

у меня все время ошибка когда я запускаю UnarcDllExample.exe x archive.arc

я похож на телепата? пиши какая конкретно ошибка, с логом


Цитата:

а почему арк спрашивает ввод пароля (

читай доку. если не читаешь - используй gui для создания архивов

Цитата:

почему альфы идут именно с циферкой *.91 ?

а какой им номер давать? если я собираюсь выпустить версию 3.0, то альфы к ней логично нумеровать как 2.9x


Цитата:

Пик памяти в срепе написано 525мб, в диспетчере задач показывает 700мб+ (потом постепенно уменьшается). Это из-за выделения кусочков оперативки кратной размеру страницы памяти в винде или фрагментации памяти?

фрагментации. кроме того, я добавляю по 16 байт на заголовки блоков памяти - может, этого мало. и ещё я не учитываю память, занимаемую дескрипторами matches (ещё байт по 30)


Цитата:

а при упаковке получитьэту информацию можно?

а зачем? распаковка в nul быстрая..

Добавлено:

Цитата:

Пик памяти в срепе написано 525мб, в диспетчере задач показывает 700мб+

кстати, для таких вещей очень удобно использовать procexp от sysinternals. открываешь окно процесса, по его завершению видишь и макс. память, и даже граф её использования:

Ahf
в настройках метода сжатия есть Экспериментальные методы

Bulat_Ziganshin

Цитата:

а зачем? распаковка в nul быстрая..

не факт что будет быстрая на нормальном наборе данных, а нормального набора у меня под рукой нет

srep32i.exe -m3f -l128 xcmd.TAR.pcf xcmd.TAR.pcf_128.srep

copy xcmd.TAR.pcf_128.srep nul

srep32i.exe -d xcmd.TAR.pcf_128.srep nul
Compression ratio: 3482909069 -> 240672545: 6.91%. Cpu 96.205 mb/sec, real 90.177 mb/sec. Matches 0 183001 5766988, memory 0mb 68mb 975mb

copy xcmd.TAR.pcf_128.srep nul

srep32i.exe -d -nomd5 xcmd.TAR.pcf_128.srep nul
Compression ratio: 3482909069 -> 240672545: 6.91%. Cpu 164.022 mb/sec, real 150.756 mb/sec. Matches 0 183001 5766988, memory 0mb 68mb 975mb

Добавлено:

Цитата:

кстати, для таких вещей очень удобно использовать procexp от sysinternals.

а так и делаем...
"...жизнь такая"

Добавлено:

Цитата:

а зачем? распаковка в nul быстрая..

кстати столько требуется памяти на распаковку у LostPlanet2.srep?

Цитата:

1) 22 gb file from LostPlanet2 compressed down to 7 gb and require 2 gb of RAM for decompression. For comparison, REP:2gb compressed the same file only to 8.7 gb - i.e. 20%

Добавлено:
тьфу ты 2ГБ, так ведь понимаете что такое 2ГБ для x86 системы?
придётся делать обычную распаковку

Bulat_Ziganshin
у меня выходит отчет об ошибке (dwwin.exe), ну это не важно

а насчет пароля, в том то и дело что я его через GUI и создаю
но так как пароли нельзя вводить пустые то его никак не откроешь и смысла нет так создавать архивы, только если в паре с старой unarc.dll
т.е. я даже не хочу с паролем шифровать каталоги архива а просто , а он его запрашивает при попытке открытия
(упаковка аналогичная через GUI делается также)

[more=листинг]C:\unarc>arc a -mlzma -dmaes archive
FreeArc 0.67 (September 10 2011) creating archive: archive.arc
Compressed 6 files, 567,959 => 367,315 bytes. Ratio 64.6%
Compression time: cpu 0.30 secs, real 0.28 secs. Speed 2,019 kB/s
All OK

C:\unarc>unarcc x -dpdir-old-version-unarc archive.arc
filename 0 0 UnarcDllExample.cpp
read 0 0
write 0 0
filename 0 0 unarcc.exe
write 0 0
filename 0 0 UnarcDllExample.exe
write 0 0
filename 0 0 unarc.dll
write 0 0
filename 0 0 pwd-11111-unarc.arc
write 0 0
filename 0 0 unarc.arc
write 0 0
read 0 0
write 0 0
quit 0 0
FreeArcExtract() was successful

C:\unarc>arc x -dpdir archive.arc
FreeArc 0.67 (September 10 2011) extracting archive: archive.arc

Enter decryption password:

ERROR: bad password for archive archive.arc

C:\unarc>unarcc x -dpdir-new-version-unarc archive.arc

C:\unarc>[/more]
....
только что еще раз перепроверил все в GUI
если упаковать допустим так lzma+aes-256, потом открыть файл и перепаковать любым другим методом то также выйдет запрос пароля
вот листинг в консольной версии (а если --recompress не использовать с u/f то не перепаковывается с переданным методом)
[more=листинг]
C:\unarc>arc a -mlzma+aes unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressed 6 files, 820,471 => 622,927 bytes. Ratio 75.9%
Compression time: cpu 0.42 secs, real 0.33 secs. Speed 2,500 kB/s
All OK

C:\unarc>arc u --recompress -mppmd unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressing 6 files, 820,471 bytes. Processed 0%
Enter decryption password:
1%arc: write: invalid argument (Bad file descriptor)


C:\unarc>arc u -mppmd unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressed 6 files, 820,471 => 622,927 bytes. Ratio 75.9%
Compression time: real 0.06 secs. Speed 0 kB/s
All OK

C:\unarc>arc lt unarc.arc
FreeArc 0.67 (September 10 2011) listing archive: unarc.arc

Archive type: FreeArc
Total bytes: 820,471
Compressed bytes: 622,927
Ratio: 75.9%

Directory blocks: 1
Directory, bytes: 222
Directory, compressed: 187
Solid blocks: 1
Avg. blocksize: 801 kb

Compression memory: 2869 kb
Decompression memory: 1066 kb
Dictionary: 810 kb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -

Encryption algorithms: aes-256/ctr

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
* 31 820,471 622,927 6 lzma:810kb:normal:32+a
es-256/ctr:n1000:r0
-----------------------------------------------------------------------------
6 files, 820,471 bytes, 622,927 compressed
All OK

C:\unarc>arc a -mppmd unarc.arc
FreeArc 0.67 (September 10 2011) updating archive: unarc.arc
Compressed 6 files, 820,471 => 647,921 bytes. Ratio 78.9%
Compression time: cpu 0.66 secs, real 0.72 secs. Speed 1,142 kB/s
All OK

C:\unarc>arc lt unarc.arc
FreeArc 0.67 (September 10 2011) listing archive: unarc.arc

Archive type: FreeArc
Total bytes: 820,471
Compressed bytes: 647,921
Ratio: 78.9%

Directory blocks: 1
Directory, bytes: 193
Directory, compressed: 160
Solid blocks: 1
Avg. blocksize: 801 kb

Compression memory: 48 mb
Decompression memory: 48 mb
Dictionary: -

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 820,471 647,921 6 ppmd:10:48mb
-----------------------------------------------------------------------------
6 files, 820,471 bytes, 647,921 compressed
All OK
C:\unarc>
[/more]

Цитата:

не факт что будет быстрая на нормальном наборе данных

future-lz распаковывает очень быстро, так что всё ограничивается скоростью твоих винтов. при распаковке в nul, соответственно - только скоростью чтения сжатого файла. вот на примере того 22-гигового файла:

Код: G:\>srep.exe lp2.pcf.srep u:\lp2.pcf
Compression ratio: 22069494174 -> 7008860732: 31.76%. Cpu 270.601 mb/sec, real 100.478 mb/sec. Matches 0 174390 1449482, memory 0mb 1798mb 13610mb

G:\>srep.exe lp2.pcf.srep nul
Compression ratio: 22069494174 -> 7008860732: 31.76%. Cpu 272.687 mb/sec, real 180.636 mb/sec. Matches 0 174390 1449482, memory 0mb 1798mb 13610mb

Попался мне архивчик с использованием precomp и нужно его распаковать.
Код: FreeArc 0.67 (May 22 2012) listing archive: data1.arc

Archive type: FreeArc
Total bytes: 4,049,156,024
Compressed bytes: 1,127,225,672
Ratio: 27.8%

Directory blocks: 1
Directory, bytes: 59,107
Directory, compressed: 17,142
Solid blocks: 2
Avg. blocksize: 1931 mb

Compression memory: 4096 mb
Decompression memory: 4096 mb
Dictionary: precomp:4096mb+lzma:64mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 22 storing
31 4,049,156,024 1,127,225,672 1,439 precomp+srep:mem512m:m
3f:a1:l512+lzma:64mb:normal:bt4:128
-----------------------------------------------------------------------------
1,461 files, 4,049,156,024 bytes, 1,127,225,672 compressed
All OK

Bulat_Ziganshin

Цитата:

Цитата: кстати, для таких вещей очень удобно использовать procexp от sysinternals.

а так и делаем...

Цитата:

можно конкретней, в чём проблема? у меня такой принцип - "precomp042" и т.п. означают конкретные версии precomp, а "precomp" заменяется на "precomp042" или другую свежую версию. это позволяет сжимать с -m=precomp и не думать, какая там сейчас версия последняя - например, не менять батники

единственное в чём возможно я неправ - это надо перенести определение precomp в стандартный arc.ini

Именно, только через арк.ини. Тк не всегда это удобно, да еще и там jpg сжатие отключено. Только вот большая проблема в том, что unarc.dll теперь не распаковывает эти архивы - пишет что неизвестный метод сжатия "precomp042:c-:t-j". В этом то и вся суть...

Цитата:

просто как бы найти способ поточнее подсчитывать память, а то может ведь и в 2 раза отличие быть.Цитата:

пока - только с помощью внешних программ, да и -l32 пока не очень жизнеспособен. это всё же самая первая экспериментальная версия, и распаковщик в ней самый простой и прямолинейный - как new/delete отработает, так и выйдет. я могу сделать собственный аллокатор памяти для этого процесса - он будет более предсказуем


Цитата:

только останется выяснить какие файлы на каком участке будут находится)и как их потом отсортировать в требуемом порядке при заTARивании в архив перед сжатием в srep.

1. несложно - обработать precomp'ом файлы по отдельности и получишь все размеры
2. используя gnu tar:

>tar cvf a.tar -Tlist
srep4.cpp
srep2.cpp
srep1.cpp
srep3.cpp

Цитата:

а насчет пароля, в том то и дело что я его через GUI и создаю

ну-ка, ну-ка, покажи мне как ты через gui без использования ручного ввода опций задаёшь эту команду "arc a -mlzma -dmaes archive". ещё раз - если ты неспособен прочесть доку и просто наугад тыкаешь в кнопочки, то при создании архива просто отметь галочку "шифрование". всё остальное программа сделает сама

egor23

Вот ссылка на репак: Dragon Age Origins - Diamond Edition
Нужен только первый образ - DAODE_RusEng_RePack_DVD1.iso
Файл с которым я мучался называется Daodata1.arc, лежит в каталоге Data.
Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб), каждый из которых содержит внутри множество файлов. Я распаковывал последовательно и проблема была практически на каждом этапе распаковки, пока я не увеличил файл подкачки.

Проблема решилась, но если будут еще вопросы - буду рад ответить

1noObman1
я ответил в другом форуме:


Цитата:

1. расшифровка методов сжатия выполняется до проверки External compressors и независимо от неё
2. раньше precomp использовался всеми как им вздумается, сейчас у него появился встроенный в arc.exe смысл. то же самое произойдёт например если я встрою srep в программу. я тут вижу неудобство для тех, кто его раньше использовал, но это ж экспериментальные внешние упаковщики, их пользователи должны знать что гарантий совместимости с будущими версиями нет?
3. что ты предлагаешь сделать? я вижу проблему в том что "перехватил" популярное название метода внешнего сжатия, даже если оно использовалось по разному разными людьми

Цитата:

Именно, только через арк.ини. Тк не всегда это удобно, да еще и там jpg сжатие отключено.

а в чём проблема использовать другой метод сжатия? назови его xcomp и определяй как угодно


Цитата:

Только вот большая проблема в том, что unarc.dll теперь не распаковывает эти архивы

т.е. раньше ты давал своё определение precomp (или даже просто использовал встроенное), создавал с ним архивы и теперь эти архивы не распаковываются, поскольку определение поменялось?

смотри - если я оставляю своё новое определение precomp=precomp042:t-j, но переношу его в arc.ini, то у тебя появляется возможность его отключить, но тогда у тебя перестанут работать новые галочки Experimental compressors. и более того, ты будешь создавать архивы с методом precomp, т.е. несовместимые с другими пользователями программы. т.е. это решит твою текущую проблему, но создаст ещё больший бардак в будущем

полноценным решением я вижу признание того, что название precomp уже "захвачено", втч и в настройках arc.ini предыдущих версий freearc, и использование вместо него чего-то нового, скажем unpack

Добавлено:

Цитата:

Что не так с precomp'ом?

это внешний компрессор, надо знать какое у него было определение при упаковке. советую поставить старый freearc, посмотреть какой exe он пытается вызвать и поставить его у себя


Цитата:

скорость упаковки идёт катастрофически медленная.

для precomp это решается запуском на ram-диске (он эти 50 гбайт пишет в текущий каталог), для srep - использованием -m1/m1f

srep 2.91 уже сейчас стоит использовать как оптимизированную версию обычного srep. опять же, на этом 22 гб файле:
-m3: RAM 16 mb, 1152 тысячи чтений из выходного файла
-m3f -m4k: RAM 258 mb, 294 тысячи чтений из выходного файла
-m3f -m128k: RAM 950 mb, 8 тысяч чтений из выходного файла

Bulat_Ziganshin

Цитата:

несложно - обработать precomp'ом файлы по отдельности и получишь все размеры

я себе представляю немного другую ситуацию - есть пару сотен (а может и тысяч) файлов в десятках папок, все без сжатия засунуты в любой из архиваторов, затем с помощью srep проводится поиск совпадений. Как тут отсортировать?) arc.exe v data.arc показывает именно ту последовательность, в которой на самом деле и упакованы файлы в arc-архив, или же сортируются перед отображением? Если первый вариант, то возможно как-то найти нужные последовательности, хоть и геморно. Может удастся и автоматизировать подобный процесс сортировки с учетом данных от срепа..

Цитата:

да и -l32 пока не очень жизнеспособен

но бывает иногда стреляет и очень прилично)

экспресс тест (каждая операция проходила после перезагрузки Win7, дабы избежать излишнего кеширования от предыдущего прохода):
data.arc = 3 909 512 074 байт
data1.srep, data2.srep ~ 2 603 705 000 байт

упаковка:
srep -m3 -l32 data.arc data1.srep - 505.37 сек
srep -m3 -l32 -f data.arc data2.srep - 511.08 сек

распаковка
srep -d data1.srep - 95.68 сек
srep -d data2.srep - 97.20 сек

З.Ы. кеширование рулит?

Пик использования памяти при распаковке второго архива в srep 525mb, в диспетчере Peak Private Bytes ~ 650mb

Бесспорно в 2.91 версии распаковка на много эффективнее...но я это могу увидеть только на очень большом объеме данных (типа твоего примера с LostPlanet2), или вынув пару планок оперативки, либо откатившить на WinXP..

Aroyl

Цитата:

Я распаковывал последовательно и проблема была практически на каждом этапе распаковки, пока я не увеличил файл подкачки.

теперь буду знать еще одну рекомендацию, если у человека не распаковываются архивы)

возможны различные сценарии использования SREP и тут меня интересуют ваши мнения, ваши запросы

на мой взгляд, самый сильный сценарий выглядит так: сжатие напрямую в arc с цепочкой алгоритмов precomp+srep+...+lzma. при этом если srep и precomp будут работать как фильтры при распаковке, то при инсталяции диск не будет загромождаться временными файлами, и скорость инсталяции будет очень высока, порядка 50 мб/с, так что за 5-10 минут можно будет установить любую современную игрушку, даже размером в 10-20 гб

размер используемой памяти можно ограничить таким алгоритмом: скажем пользователь при распаковке разрешает использование 500 мб ОЗУ. когда занятая программой память подходит к этому пределу, программа находит 8 мб "самых будущих" матчей и скидывает их содержимое во временный файл, запоминая где они начинаются. когда распаковка подойдёт к этому моменту, данные считываются из врем. файла одним куском. при этом, если для них нет свободной памяти, то точно так же во временный файл записываются "самые будущие" матчи из нынешнего словаря.

поскольку из всех находящихся в данный момент в памяти данных позже всего нам потребуются именно "самые будущие" матчи, то это де-факто такой интеллектуальный алгоритм своппинга, которые выкидывает в своп-файл именно те данные, которые нам не потребуются дольше всего. при этом чтение/запись этих данных производится кусками по 8 мб, т.е. никаких проблем с seek times и нагрузкой на кеш диска как у обычного srep и обычного своп-файла

оценить эффективность такого подхода можно на примере того же lp2.pcf - в нём на 22 гб данных приходятся 13 гб матчей. если ограничить потребление памяти при распаковке 200 мб, то во временный файл придётся записать (и затем прочитать) 5-10 гб данных, что при скорости диска в 100 мб/с потребует 100-200 сек. учитывая, что процесс распаковки наверняка будет CPU bound, а не I/O bound (т.е. ограничиваться скоростью CPU), этот обмен с диском будет бесплатным (т.е. не увеличит общее реальное время работы), если остальные процессы в цепочке (lzma, precomp) будут работать параллельно с srep

Добавлено:
забыл добавить - размер временного файла на диске при этом будет ограничен теми же 2 гб, просто некоторые 8мб блоки в нём будут несколько раз перезаписываться в ходе работы

Bulat_Ziganshin

Цитата:

при этом если srep и precomp будут работать как фильтры при распаковке, то при инсталяции диск не будет загромождаться временными файлами, и скорость инсталяции будет очень высока, порядка 50 мб/с, так что за 5-10 минут можно будет установить любую современную игрушку, даже размером в 10-20 гб

Идея отличная, но Вам же её и реализовать.

Лично мне в репаках игр использование srep-а не нравится именно тем, что на диск пишется ОГРОМНЫЙ файл, а потом уже он распаковывается сабжем.

Как конечному потребителю мне это кажется извращением. Я уж лучше еще за 10 минут ещё 1 гиг качну, чем ждать 40 минут всю эту канитель с усиленным дрыганьем винта и прочим бредом по распаковке со srep-ом, в текущем его состроянии.

В сферическом вакууме (если не учитывать время, дополнительное место на винчестере) srep - очень хорошая вещь.

Bulat_Ziganshin

Цитата:

по умолчанию
-m1mb
-m128k
-m4k

??
делали так?

srep32i.exe -nomd5 -d -m4k file.srep nul

а то сходу не сообразил.

Цитата:

srep32i.exe -nomd5 -d -m4k file.srep nul

ага

Добавлено:

Цитата:

Лично мне в репаках игр использование srep-а не нравится именно тем, что на диск пишется ОГРОМНЫЙ файл, а потом уже он распаковывается сабжем.

имхо, уже в srep 1.9 осталась только проблема с большим файлом, а на скорости установки его использование не должно сказываться. смотри сам - есть два варианта:

1) precomp+srep+lzma: тогда на первом проходе мы распаковываем lzma->srep->файл, затем обрабатываем файл precomp'ом. замена srep на rep здесь ничего не изменит

2) srep+lzma: тогда после распаковки lzma->srep мы сразу можем писать выходные файлы, но для работы srep нужен временный файл. т.е. места во время инсталяции нужно больше, но скорость не теряется

вопрос в том, сообразили ли репакеры так делать, ну и когда precomp наконец научится распаковывать в потоке

Добавлено:
SREP 2.92 alpha:

* 1.5x faster compression, on average (especially notable on multi-gigabyte files)

my own tests:
srep32i: 10.468 mb/sec -> 17.587 mb/sec
srep64i: 17.645 mb/sec -> 29.943 mb/sec

This version improves CPU times. In the next version i will try memory-mapped files to significantly improve I/O speeds, too