Bulat_Ziganshin
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SREP 2.91 alpha:
* -f: future-LZ compression; -m1f..-m3f as shortcuts
* -mBYTES for future-LZ decompression
* -nomd5: don't store/check MD5 checksum of every block
"srep -f infile" performs 2-pass compression, storing in the compressed file references to forthcoming LZ matches
"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
Unlike ordinal LZ compressors, decompressor's dictionary saves only data that will be really used at some future moment. This significantly reduces RAM needs. Examples:
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% more
2) dll700.dll from my testset:
184 mb: compressed with lzma:64m
177 mb: compressed with rep:256m+lzma:64m
171 mb: compressed with lzma:256m
121 mb: compressed with srep+lzma:64m, while only 200+64 mb RAM required for decompression
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 (therefore you can't decompress to stdout with -m). Example:
Код: srep -f infile
srep -m128kb infile.srep |
On future-LZ decompression additional stats are printed:
Код:| Matches 2123 3483 17796, memory 127mb 167mb 180mb |
First 3 numbers denote current, maximum so far, and total number of matches in dictionary. Last 3 numbers denote current, maximum so far, and total amount of memory used for dictionary. At the end of decompression 2nd memory value (167mb) will tell you how much memory entire decompression require (add 10% for memory fragmentation) |
