Is great . Thanks Razor12911

Is it possible to have a Multi Tasking srep? Like precomp?

Srep just needs a good drive, it isn't slow at all.

I am asking because I know 2 guys who compressed same data (20 GB), with srep+lzma on SSD and the first one packed this data in approx. 40 mins. the second one in approx. 2 hrs. And the unpacking time for the first one is about 5 mins with heavy load on CPU and DISK DRIVE whilst for the second one is about 20 mins, both on SSD. I wanted to take a look in the temp folder to see what files are generated by the setup, but they seem to be hidden. So, any ideas on this one?

RAM also needs to be considered.

RAM is 1GB during unpacking. I still can`t understand what the first guy is using, but he is definitely using something :D So my thought was that he`s been using something like precompmt but with srep instead.

Dude, there are programs that need the technique of precompmt, srep isn't one of them. For example, I made zstd multi threaded but it was only during compression, during decompression, it's like a disk is capable of 3gbps I/O, if the program itself suffers IO bottleneck from this, it doesn't mean multi threading will fix it, instead if you try to make it multi threaded, either you get 5% more speed which is not much or you lose speed overall.

Plus with regards to srep and different time taken, firstly the hardware is probably different, srep is single threaded, first guy might have had i7, second guy might have had a weaker CPU, secondly RAM, srep operates mostly using RAM, if ram speed is high, it equals to more speed, secondly with regards to ram too, bigger the better, this will make windows not adjust itself to keep system alive, those adjustments actually contribute to bottleneck, SSDs as well are also different. Too many variables, but all depend on hardware, SrepMT will not solve this. It's like trying to make wheels of an airplane work while on midair, those wheels will just spin but they will make little or no difference whatsoever.

srep doesn't need multithreading. or, srep is m/t already, but second thread is only 10% or so of the main one. and srep offloads i/o to separate thread

let's see - in -m3 mode, you can use higher -a value to boost speed. with -a16 i get >500 MB/s - much-much fasterthan any lzma

in -m4/m5 mode it has even less computations to perform, but limited by I/O speed. yeah, on SSD multithreading I/O should be a good idea - you are right here

lzma may be multithreaded too, like lzham/rar5

Thanks everyone for the reply. I will test soon.

the best thing is that it works with compression & dec.. unlike the one made by ProFrager it works only in dec.. however i prefere the cls for both :)

i have Problem, i compression Max Payne 3 Only files needd with pZLib version 2 + SREP 3.93 beta + lzma:a1 and after done compression say need 7600mb ram for decompression I want limited ram uesd decompression srep I tried in every way using this and does not help

[External compressor:srep]
header = 0
unpackcmd = srep -mem228b {options} -d -s - - <stdin> <stdout>

[External compressor:srep]
header = 0
unpackcmd = srep -mem512mb {options} -d -s - - <stdin> <stdout>

[External compressor:srep]
header = 0
unpackcmd = srep --mem75% -d -s - - <stdin> <stdout>

or --mem50% or --mem25%

Also edited inside
innosetup

if not SrepInit('',228,0) then break;
if not PrecompInit('',128,PCFVer) then break;
if not FileSearchInit(true) then break;

and Still used more than 5gb ram and I have another problem
why srep withme uesd virtual memory Load on ram not HDD
i want Create virtual memory temp on HDD how do this?

look photos

https://s18.postimg.org/f5yyw9nsp/Untitled.png

https://s16.postimg.org/5viyermsl/image.png

This was happened because you added srep two times in arc.ini remove one of them and everything will be fine again. ;)

No, not the cause of this i used one srep in arc.ini
I unpack file with method this pzlib+srep+lzma:a1:mfbt4:d512m:fb273:mc1000:lc8
by Install Run in innosetup i try with BlackBox_2.5.1 and BlackBox_2.5.0 and Impossible unpack say CRC Check

I think not supported unarc.dll for this method And surely i add

[External compressor:pzlib]
header = 0
unpackcmd = pZLib d -t8 - -o - <stdin> <stdout>

in arc.ini and sill CRC Check

@CAT8K it's normal because u used a16 option which require more much ram
so the bigger the file size the more much ram will require so try a1\a2 instead oh a16 & see if something will change :)

Thanks bro I try with -m3f -a4 or a2 but first i make test on just 2gb files with pzlib Will become up 4gb if come
Fine Then i make mp3 again 21gb with pzlib