Helping thread :)

[Bulat]

Yesterday i had very productive debuggng seesion with MCWRX and he helped me to understand why srep+4x4:lzma is hard to master:

InsertTempfile procedure i already mentioned is fired in unarc.dll to adopt decompression algorithms to the real memory available. But on decompression stage, we don't have too much choices - eithe insert "tempfile" between methods and save intermedirte data to the tempfile or limit 4x4 to run less threads simultaneously

With built-in algos, it works fine (modulo bugs), but for external algos including srep there is no any API to limit their memory usage! so, many years ago i developed alternative approach specially to srep - it can be parameterized like srep:mem75%-600mb and this way it will alloc 75% of RAM minus 600 MB. It was supposed that you have compression line like srep+delta+lzma:512m, computed memory usage by remaining algorithms and make appropriate srep setting

It was fine for all built-in algos except for 4x4, whose decompression memory depends on the num_cores and thus cannot be predicted at compression time. So, we just don't have working instrument for limiting srep+4x4 by using only MY tools

Nevertheless, in MCWRX installer memory usage for srep is set by the installer script. I don't looked into details, but obviously community provided right instrument to deal with srep+4x4 case. Unfortunately, it needs some programming skills to manage - you need to find num_cores, compute memory usage of remaining algos, find RAM size, and then compute memory available for srep. And if it becomes too small (say, less than 500 MB) i recommend to limit number of 4x4 threads (by modifying compression string replacing 4x4 with 4x4:t4 or so) in order to prevent excessive disk swapping in srep

Yet another solution will be improvement of :mem language, adding support for smth like mem75%-100m-132m*t

And ideal solution will be implementation of srep as builtin method or just 64-bit unarc.dll. the second way looks much simpler so i will try