Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор - Часть 3

Модерирует : gyra, Maz

Widok (23-11-2010 11:37): Лимит страниц. Продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

   

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

FreeArc
бесплатный open-source архиватор для Windows и Linux,
сочетающий высокую степень сжатия и большой набор возможностей


Официальный сайт | Скриншоты | Лента новостей
Документация на консольную версию | Документация на GUI версию
Сообщество пользователей FreeArc | Вики | Трекер (рассылка по ошибкам)
Проект на SourceForge.net | SVN-репозиторий | Поддержка InnoSetup
Обсуждение на encode.ru (англоязычное)

Скачать последний релиз - FreeArc 0.666 от 20 мая 2010 г. Что нового: ускорение работы в 1.5-2 раза благодаря новой технологии многопоточного сжатия, распаковка архивов многих форматов используя технологии 7-zip, запуск файлов из архива, исправлены все проблемы интеграции с Explorer (подробнее)
 
Текущая альфа версия: 0.67 - загрузка | список исправлений | блог

FAQ по FreeArc

Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну... | И немного о будущем...
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Планы дальнейшего развития
Что подразумевается под "интеграцией с Explorer"
Старая FreeArc wiki (включая описание формата архива)
Логотип - объявляется конкурс на иконки для FreeArc

Сторонние оболочки для работы с FreeArc:
  • wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
  • PeaZip - менеджер архивов с поддержкой большого количества форматов, для Windows и Linux
     

    Родственные темы:
  • Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах
  • Пережатиe/Pекомпрессия/Oптимизация файлов для лучшего сжатия - "а как сжать ещё лучше?"
  • FreeArc и Unix - для альтернативно одарённых
     
    Другие архиваторы:
  • WinRAR
  • 7-zip

  • Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 19:15 07-09-2009 | Исправлено: Bulat_Ziganshin, 18:34 26-07-2010
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    обновил http://freearc.org/download/testing/srep.exe и добавил 64-битный http://freearc.org/download/testing/srep64.exe
     
    теперь они выводят сжатые данные, но распаковки пока нет

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 21:45 22-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    now decompression works too. i've constructed the following batch for its testing:
     
    timer srep.exe %1 1
    timer srep.exe -d 1 2
    arc a a -mcrc %1 2
    arc v a
     
    archive listing given by las command should show the same CRC values for both files

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 01:14 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    srep.exe


    взял файлик iso 7678.5МБ, сделал копию, заtarил, получил файлик 1.tar 15357МБ
    srep.exe 1.tar 2222
    1792 mb used for hash (filesize/12, rounded up to power of 2)
    Compression ratio: -1076818944 -> 3:  0.00%
     
    файлик 2222 имеет размер 7633.1МБ (данные в iso возможно немного сжимаемые)

    Цитата:
    512 mb used for hash (filesize/12, rounded up to power of 2)

    требования к памяти: filesize/12 + 2*256МБ
     
    Добавлено:
    srep.exe использовался от "21:45 22-11-2009"
    неплохо дату:время вставлять, чтобы путаницы не было с версиями ПО.
     
    Добавлено:
    Bulat_Ziganshin

    Цитата:
    constructed the following batch for its testing:

    timer.exe srep.exe 1.tar 2222
    timer.exe srep.exe -d 2222 3333
    + весёлые картинки Process Explorer, (скорость диска ~60МБ\с)
     
    timer.exe srep.exe 1.tar 2222
     
    Timer 3.01  Copyright (c) 2002-2003 Igor Pavlov  2003-07-10
    1792 mb used for hash (filesize/12, rounded up to power of 2)
    Compression ratio: -1076818944 -> 3:  0.00%
     
    Kernel Time  =    73.468 = 00:01:13.468 =   5%
    User Time    =  1203.078 = 00:20:03.078 =  83%
    Process Time =  1276.546 = 00:21:16.546 =  88%
    Global Time  =  1443.828 = 00:24:03.828 = 100%
     

     
    timer.exe srep.exe -d 2222 3333
     
    Timer 3.01  Copyright (c) 2002-2003 Igor Pavlov  2003-07-10
    Compression ratio: -1076818944 -> 3:  0.00%
     
    Kernel Time  =   172.359 = 00:02:52.359 =  21%
    User Time    =    33.062 = 00:00:33.062 =   4%
    Process Time =   205.421 = 00:03:25.421 =  25%
    Global Time  =   817.828 = 00:13:37.828 = 100%
     

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 02:45 23-11-2009 | Исправлено: egor23, 02:53 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    требования к памяти: filesize/12 + 2*256МБ

    filesize/12 + 2*XXXМБ
    по какому принципу XXX выбирается?

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 04:59 23-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    filesize/12, округлённое вверх до степени 2. в последней версии 7/8 от этого объёма. далее ещё чуть уменьшу, будет 6-8% от размера файла

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 10:57 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    filesize/12, округлённое вверх до степени 2

    не совсем понял про округление
    было выделено filesize/12 + 2*256МБ
    filesize/12 - "ровно" 1\12, т.е 15357\12 = 1280МБ
     
    подтянулись реальные данные Devil.May.Cry.4
    http://forum.ru-board.com/topic.cgi?forum=5&topic=29437&start=1340#9
    2.205 files of 7.702.106.956 bytes
    заtarены в DEVILMAYCRY4.TAR 7347МБ
     
    timer.exe srep.exe DEVILMAYCRY4.TAR 2222
    timer.exe srep.exe -d 2222 3333
    + весёлые картинки Process Explorer, (скорость диска ~60МБ\с)
     
    timer.exe srep.exe DEVILMAYCRY4.TAR 2222
     
    Timer 3.01  Copyright (c) 2002-2003 Igor Pavlov  2003-07-10
    896 mb used for hash (filesize/12, rounded up to power of 2)
    Compression ratio: -886002176 -> 1:  0.00%
     
    Kernel Time  =    87.875 = 00:01:27.875 =  12%
    User Time    =   501.828 = 00:08:21.828 =  73%
    Process Time =   589.703 = 00:09:49.703 =  86%
    Global Time  =   684.703 = 00:11:24.703 = 100%
     
    файлик 2222 получился 2861.4МБ
    задача была приблизиться к 2759МБ (столько весят эти данные в RIP-е)
    дожимаем: WinRAR скоростной - 2731.9МБ, что близко к цифре 2725МБ, которая была ранее
    http://forum.ru-board.com/topic.cgi?forum=5&topic=29437&start=1340#21
     

     
    timer.exe srep.exe -d 2222 3333
     
    Timer 3.01  Copyright (c) 2002-2003 Igor Pavlov  2003-07-10
    Compression ratio: -886002176 -> 1:  0.00%
     
    Kernel Time  =    75.640 = 00:01:15.640 =  25%
    User Time    =    16.281 = 00:00:16.281 =   5%
    Process Time =    91.921 = 00:01:31.921 =  30%
    Global Time  =   300.531 = 00:05:00.531 = 100%
     

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 11:26 23-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    не совсем понял про округление
    было выделено filesize/12 + 2*256МБ  

    1280мб округлённое вверх до степени 2 = 2048 мб
     
    ты распакованный файл с орнигиналом сравнивал? по crc/md5...
     
    в srep64 есть ошибка - он не распаковывает файлы больше 2 гиг

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 11:39 23-11-2009 | Исправлено: Bulat_Ziganshin, 11:40 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    ты распакованный файл с орнигиналом сравнивал? по crc/md5...

    конечно, по md5 всё совпало

    Цитата:
    1280мб округлённое вверх до степени 2 = 2048 мб

    srep 32-bit, Win32 (VM 2ГБ)
    было выделено 1280 +2*256МБ = 1792МБ (это что было)
    версия srep от "01:14 23-11-2009"
    или округление вверх до степени 2 в новой версии будет, 1280 до 2048МБ как-то не очень катит, или это округление в srep 64-bit?
     

    Цитата:
    файлик 2222 получился 2861.4МБ  
    задача была приблизиться к 2759МБ (столько весят эти данные в RIP-е)
    дожимаем: WinRAR скоростной - 2731.9МБ, что близко к цифре 2725МБ, которая была ранее

    дожимаем 2222 rep с разными настройками:
    rep:128m - 2739.6МБ
    rep:128m:64 - 2730.3МБ
    rep:128m:32 - 2729МБ
    rep:128m:16 - 2728.1МБ
     
    непонял?!
    srep.exe -l256 DEVILMAYCRY4.TAR 2222_256
    Can't allocate memory: 1792 mb required (filesize/12, rounded up to power of 2)
     
    srep.exe -l128 DEVILMAYCRY4.TAR 2222_128
    Can't allocate memory: 3584 mb required (filesize/12, rounded up to power of 2)
     
    srep.exe -l64 DEVILMAYCRY4.TAR 2222_64
    Can't allocate memory: 7168 mb required (filesize/12, rounded up to power of 2)

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 12:29 23-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    1280мб округлённое вверх до степени 2 = 2048 мб. 7/8 от этого - 1792 мб
     
    Добавлено:

    Цитата:
    Can't allocate memory: 1792 mb required

    из-за фрагментации памяти. хотя непонятно, почему в прошлый раз выделилось а в этот нет...
     
    Добавлено:
    да, объм выделяемой памяти прямо пропорционален l. написанное в скорбках верно только для -l512

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 12:41 23-11-2009
    Ghost2004

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Здорово, классная вышла программа. У меня на Атлоне 64 X2 с 2.2 ГГц (вот только память там DDR314 двухканальная) скорость сжатия вышла в районе 6 Мб/с для плохо сжимаемых данных, и 10-15 Мб/с - для PS2-игры, которую с одной DVD9 запихнули на 2 DVD5 - т.е. с массой повторов. Жёсткие диски у меня обычно выдают порядка 40 Мб/с.
     
    Короче, результаты (для 0.2 версии 32-битной) вышли такие:
    3 372 449 792 rg2dvd5-1.iso -> 2 806 453 152 rg2dvd5-1.l512.srep
    Полное время сжатия - 513 сек, распаковки - 215 сек.
    4 533 911 552 rg2dvd5-2.iso -> 3 823 207 128 rg2dvd5-2.l512.srep
    Полное время сжатия - 761 сек, распаковки - 287 сек.
     
    Оба образа запихнутые в один тар:
    7 906 363 392 bc-rg2dvd5-1+2.tar -> 4 238 863 720 bc-rg2dvd5-1+2.l512.srep
    Полное время сжатия - 727 сек(правда, тут скорее всего сыграл ещё тот факт, что с другого физического диска сжималось), распаковки - 515 сек.  
     
    Что интересно, объём прочитанного (в диспетчере задач) оказывается близок к 4xразмер исходного файла. Правда, тут наверное много чтений из кэша.
     
    Во всех случаях не только crc распакованные совпали, но и побайтовое сравнение в Totalcmd выдало идентичные файлы.
     
    К сожалению, распаковка в этой версии (0.2) не работает, если при сжатии выставить мин. длину отличную от стандартных 512 (пробовал 2048 и 4096 - выдаёт ошибку - а они ведь при сжатии памяти меньше требуют - в 4 и 8 раз соответственно - а то на моих win32 даже l256 вряд ли пройдёт для 7 Гб-ного файла).
     
    Да, и ещё: обнаружил одну ошибку в freearc'е - даже версия 18-ого ноября у меня при -mex5 выдаёт "ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb".
     
    Что интересно - в том наборе было много (порядка 50-ти) файлов .tga - так вот, на их сжатии mm+grzip и даже просто grzip сильно снижает скорость. Даже в m8b lzma быстрее. Насчёт упаковки точно сейчас не вспомню, а вот при распаковке отключение grzip'а даёт 15 Мб/c (m8b или mex4 с отключённым grzip'ом). Выключение mm даёт 9.5 Мб/с для ex4, а вот режим по умолчанию, где каждому tga-файлу выделяется по солид-блоку - лишь 4 Мб/с. Хотя mx по умолчанию ещё медленней - наверное текстовый компрессор не свои файлы решил сжимать - скорость распаковки до 2.6 Мб/с упала. При этом размеры архива мало отличаются - плюс-минус 400 кб к общему размеру 21 Мб. И лучше всех вариантов сжимает m8b. Да, а размер исходных файлов - сейвы одной игрушки - всего около 56 Мб.

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 13:14 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    srep.exe -l256 DEVILMAYCRY4.TAR 2222_256  
    Can't allocate memory: 1792 mb required (filesize/12, rounded up to power of 2)

    с этим разобрался, было недостаточно памяти
     
    timer.exe srep.exe -l256 DEVILMAYCRY4.TAR 2222_256
    2222_256 = 2928.6МБ
    Timer 3.01..
     
    timer.exe srep.exe -l1024 DEVILMAYCRY4.TAR 2222_1024
    2222_1024 = 2830.5МБ
    Timer 3.01..
     
    timer.exe srep.exe -l2048 DEVILMAYCRY4.TAR 2222_2048
    2222_2048 = 2822.1МБ
    Timer 3.01..
     
    timer.exe srep.exe -l4096 DEVILMAYCRY4.TAR 2222_4096
    2222_4096 = 2832.3МБ
    Timer 3.01..
     
    timer.exe srep.exe -l8192 DEVILMAYCRY4.TAR 2222_8192
    2222_8192 = 2857.8МБ
    Timer 3.01..

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 13:39 23-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    srep 0.6:
     
        * fixed 64-bit version, now it properly handles files >2gb
        * fixed decompresion with non-default -l
        * -s prints stats after each block
     
     
     
    Добавлено:

    Цитата:
    а то на моих win32 даже l256 вряд ли пройдёт для 7 Гб-ного файла

    как я уже писал, в приницпе до 24 гб должно быть нормально. хотя из-за фрагментации памяти могут быть проблемы. я ещё уменьшу требованию к озу, особенно к самому большому куску, выделяемому для хранения sha1
     

    Цитата:
    даже версия 18-ого ноября у меня при -mex5 выдаёт "ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb".  

    я это исправил в тот же день, просто перекачай freearc

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:58 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Ghost2004

    Цитата:
    а то на моих win32 даже l256 вряд ли пройдёт для 7 Гб-ного файла).

    пойдёт сделайте например папку srep.exe.local
    а в ней поместите dll-ки, с изменёнными базовыми адресами (расчитите адресное пространство процесса srep.exe)
    http://forum.ru-board.com/topic.cgi?forum=5&topic=29437&start=1660#9

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 14:19 23-11-2009 | Исправлено: egor23, 14:20 23-11-2009
    Ghost2004

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    хотя из-за фрагментации памяти могут быть проблемы.

    Угу, у меня без антивируса и прочих программ бывал макс. свободный блок 1700 Мб (сейчас-то вообще 1450 Мб - хотя это может и можно немного увеличить) но до 1792 Мб по-моему ни разу не дотягивал. Так что придётся ограничиться 12 Гб для l512 - а для 24 уже использовать l1024... В принципе не критично - 2048 может оказаться оптимальным, судя по тесту выше над Devil May Cry . А с такой длиной предел даже для нынешней версии и 32 бит, при максимальном непрерывным блоке меньше 1792, но больше 896 МБ - целых 32 Гб.
     

    Цитата:
    я это исправил в тот же день, просто перекачай freearc

    Что-то не работает, откуда качать? В шапке этой темы все версии с такими датой и временем:  18.11.09 12:52 - как раз как у меня, которая всё равно ту ошибку выдаёт.
     
    Добавлено:
    Так, у меня srep 0.6 версии (32 bit) неминуемо вылетает при запуске. Разве что 8 Мб записать успевает - да толку... А фокус с перебазированием dll'ок надо будет попробовать...

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 14:34 23-11-2009
    Sig666

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    srep 0.6:  

    на WinXP SP2  программка не работает
    вылетает с предложением отправить отчет через пару сек после начала операции

    Всего записей: 134 | Зарегистр. 15-01-2008 | Отправлено: 15:06 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    программка не работает

    srep.exe - Ошибка приложения
    Инструкция по адресу "0x77c32a16" обратилась к памяти по адресу "0xdc847af4". Память не может быть "read".
     
    Добавлено:
    Ghost2004

    Цитата:
     В принципе не критично - 2048 может оказаться оптимальным, судя по тесту выше над Devil May Cry . А с такой длиной предел даже для нынешней версии и 32 бит, при максимальном непрерывным блоке меньше 1792, но больше 896 МБ - целых 32 Гб.

    при 1792МБ, и 2048 длине, данных будет 96ГБ
     
    Добавлено:

    Цитата:
     В принципе не критично - 2048 может оказаться оптимальным, судя по тесту выше над Devil May Cry .

    Devil May Cry - это конкретный набор данных, в котором дожимать практически ничего не нужно, что там на других наборах будет, где не так много явных повтором, это надо смотреть...
     
    Добавлено:
    Bulat_Ziganshin
    кстати
    данные обработанные srep.exe 64bit, потом разожмутся с помощью srep.exe 32bit?

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 15:10 23-11-2009 | Исправлено: egor23, 19:50 23-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    srep 0.7:
     
        * reduced memory usage down to 6-8% of filesize. For example, 24gb file needs 256+256+960 mb chunks
        * now hash keeps address of the last chunk with the same contents
        * hashing improved a little
        * fixed WinXP crashing bug
     
    note: yes, 32-bit and 64-bit versions are 100% compatible with each other

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 16:29 23-11-2009 | Исправлено: Bulat_Ziganshin, 21:45 23-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin

    Цитата:
    reduced memory usage down to 6-8% of filesize.

    а как сейчас объём памяти расчитывется?
     
     
    timer.exe srep.exe DEVILMAYCRY4.TAR 2222
     
    Timer 3.01  Copyright (c) 2002-2003 Igor Pavlov  2003-07-10
    542 mb used for hash
    Compression ratio: 7703932416 -> 2998132028: 38.92%. Cpu 15.998 mb/sec, real 13.504 mb/sec
    Kernel Time  =    21.375 = 00:00:21.375 =   3%
    User Time    =   481.562 = 00:08:01.562 =  84%
    Process Time =   502.937 = 00:08:22.937 =  88%
    Global Time  =   570.719 = 00:09:30.719 = 100%
     
    2222 = 2859.2МБ
    дожимаем: rep:128m:64 - 2222_rep128_64.arc = 2729.2МБ
     
    timer.exe srep.exe -d 2222 3333
     
    Timer 3.01  Copyright (c) 2002-2003 Igor Pavlov  2003-07-10
    Compression ratio: 7703932416 -> 2998132028: 38.92%. Cpu 475.460 mb/sec, real 26.814 mb/sec
    Kernel Time  =    73.671 = 00:01:13.671 =  25%
    User Time    =    16.218 = 00:00:16.218 =   5%
    Process Time =    89.890 = 00:01:29.890 =  31%
    Global Time  =   288.375 = 00:04:48.375 = 100%

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 17:18 23-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

    Цитата:
    а как сейчас объём памяти расчитывется?  

    filesize*20/L + округлённое_вверх(filesize*8/L * 4/3)
     
    а раньше было
    округлённое_вверх(filesize*(20+8)/L * 4/3)
     
    а ещё до этого
    округлённое_вверх(filesize*(20+12)/L * 4/3)

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:29 23-11-2009
    CTACKo

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Привет!
    Заменил библиотеку unarc.dll с версии 3,3 на 3,4, скачивал сегодня.  
    Возникла большая проблема - где-то начиная с 27% скорость распаковки просто нереально упала, стала в районе 0,5Мб/сек, а то и меньше. С версией 3,3 такого не было, а была стабильно высокая скорость распаковки.
    О! Вот это да... Оказывается происходило следующее - в бесконечном цикле распаковывались одни и те же файлы в одном из подкаталогов. Затем они по очереди занулялись и распаковывались снова (это были wav-файлы), т.е. типа повторной распаковки. В итоге около получаса или больше распаковка топталась на одном месте и затем, наконец, молча завалила себя и инносетап в придачу...
    Архив был получен джойном из 6 сжатых разными методами. Максимальная требуемая память для распаковки составляет 384Мб для нескольких из них. Макс. блок ОЗУ у меня согласно фа - 811 метров.
    К слову сказать 3,3 тоже молча отваливается на этом архиве, только значительно быстрее и где-то на 50%.
     
     
    Добавлено:
    Попробовал для джойна использовать последний доступный фа 6,00 от 18 новэмберя сг - эхвект ровно такой жо.  
    Опять джойны не пашут!
     
    Добавлено:
    Также у меня сложилось впечатление, что версия 3.4 по сравнению с 3.3 гораздо медленнее распаковывает архивы сжатые методом tta.
     
    Добавлено:
    вердикт:
    пересобрал архив объединением в другой последовательности, сначала пошло все остальное, затем то что жалось тта. 3.4 все так же начала тупить, опустив скорость где-то с 90% (визуально по п/б выглядело 1+-0.5 Мб/сек ). Не дождался я окончания этого издевательства (~600 файлов ждать оставалось), т.к. перед обломом все именно так и выглядело и думаю что он бы снова настал. Откатился на версию 3.3 и это дало эффект: скорость на тта-шках, конечно, не ахти, но заметна визуально - в несколько раз выше чем в версии 3.4 и вылета не стало, т.е. все нормально распаковалось не учитывая все же низкую скорость распаковки тта, которая составляла не более 10-15Мб/сек (в пике), а в среднем была в районе 5Мб/сек.

    Всего записей: 180 | Зарегистр. 05-09-2008 | Отправлено: 23:46 23-11-2009 | Исправлено: CTACKo, 11:16 24-11-2009
       

    Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106

    Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор - Часть 3
    Widok (23-11-2010 11:37): Лимит страниц. Продолжаем здесь


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2024

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru