ruduk
ну srep ведь прекомпрессор,и низкие значения искомых строк могут ухудшить последующее сжатие более мощным алгоритмом. В любом случае в srep есть минимальная длина искомых строк,меньше которой совпадения не будут обрабатываться, а если встретится блок бОльшего размера вплоть до размера буфера, схожий с каким-либо предыдущим большИм блоком, он будет обрабатываться как один единый блок,т.е. на него отведется всего 16байт (может и ошибаюсь с циферкой,пишу по памяти).
Т.е. ворачиваясь к ежикам, можно объяснить так, допустим имеются 2 ежика, у которых по 2000 иголок, но у второго 1992 иголок такие же как у первого, а 8-другие. Представим это в виде файлов. Имеем 2 файла с практически одинаковым содержимым размером по 2000мб, у второго 8 последних мегабайт отличаются от данных первого файла. Объединим файлы в один, чтобы среп их оба последовательно обработал. Допустим что в первом файле пересекающиеся данные не встречаются, т.е. среп в них не нашел схожие блоки, и т.к. размер буфера в среп 8 мб, то на выходе будем иметь 2000мб+ (2000/8)*16 байт на оглавление среп-файла (плюс еще пару десятков байт на блок, но суть не в этом). т.е. 2000мб+4000байт( ну мож 8кб если посчитать некоторые не указанные тут данные). При начале сканирования второго файла в потоке, среп увидит, что данные схожи с первым, при чем схожесть будет блоками размером с буфер (8мб), т.е. за записи 1992мб схожих с предыдущими понадобится (1992/8)*16 байт=3984байта (как и в предыдущем случае на самом деле будет чуть меньше 8кб) + оставшиеся 8 мб, для которых не найдены совпадения.
Т. е. я хочу сказать, что для записи больших повторов в срепе и так требуется относительно мало байт индексных данных.
ну srep ведь прекомпрессор,и низкие значения искомых строк могут ухудшить последующее сжатие более мощным алгоритмом. В любом случае в srep есть минимальная длина искомых строк,меньше которой совпадения не будут обрабатываться, а если встретится блок бОльшего размера вплоть до размера буфера, схожий с каким-либо предыдущим большИм блоком, он будет обрабатываться как один единый блок,т.е. на него отведется всего 16байт (может и ошибаюсь с циферкой,пишу по памяти).
Т.е. ворачиваясь к ежикам, можно объяснить так, допустим имеются 2 ежика, у которых по 2000 иголок, но у второго 1992 иголок такие же как у первого, а 8-другие. Представим это в виде файлов. Имеем 2 файла с практически одинаковым содержимым размером по 2000мб, у второго 8 последних мегабайт отличаются от данных первого файла. Объединим файлы в один, чтобы среп их оба последовательно обработал. Допустим что в первом файле пересекающиеся данные не встречаются, т.е. среп в них не нашел схожие блоки, и т.к. размер буфера в среп 8 мб, то на выходе будем иметь 2000мб+ (2000/8)*16 байт на оглавление среп-файла (плюс еще пару десятков байт на блок, но суть не в этом). т.е. 2000мб+4000байт( ну мож 8кб если посчитать некоторые не указанные тут данные). При начале сканирования второго файла в потоке, среп увидит, что данные схожи с первым, при чем схожесть будет блоками размером с буфер (8мб), т.е. за записи 1992мб схожих с предыдущими понадобится (1992/8)*16 байт=3984байта (как и в предыдущем случае на самом деле будет чуть меньше 8кб) + оставшиеся 8 мб, для которых не найдены совпадения.
Т. е. я хочу сказать, что для записи больших повторов в срепе и так требуется относительно мало байт индексных данных.
. Прочитал readme прописал в arc.ini ничего не выходит((( 
Оперативки 8 гб. Винда кеширует 4гига где-то) Все равно мало) 