lazyhamster
v1.12.0 - стоит оптимизировать распаковку в /SOLID контейнерах
На примере NSIS 2.5x /LZMA /SOLID - тестируем распаковку FarUE3 инсталлера (1322 файла) в Observer 1.11.2 эта операция заняла 47 секунд, в 1.12.0.14 свыше 22 минут:
что видно по набору скриншотов. Более простой архив Exact Audio Copy V1.5 от 23.02.2020 распаковался примерно за 15 секунд. Так что стоит посмотреть как избежать повторного считывания оглавления архива при распаковке - наблюдаемые потери времени связаны с этой операцией.
Я в курсе проблемы распаковки из NSIS-а. Обсуждалась уже не один раз. Как найду решение, сделаю чтобы быстро было.
Это просто напоминание что у нас есть такая задача. Больше чтобы самим не забыть и не перепроверять повторно.
Я сейчас вожусь с IntChecker.Run.lua - переделываю движок под far.RecursuveSearch() - с одной стороны она удобнее, а с другой есть интересный момент - если мы обращаемся к симлинку из файловой панели фар то плагин его обрабатывает, а если из макроса через PlaginCall() нет и в итоге получаем false в ответе. Потому я пока отключил обработку симлинков в поиске маской, но если сможем и симлинки обрабатывать было бы не плохо. Предварительный тест-скрипт корректно работающий в локальной панели могу прислать, но он (там я переделаю - сменю порядок обработки "файл - каталог" на "каталог - файл") пока не работает с объектами вида "корень тома или корень шары" - с этим сейчас вожусь, придумаю решение. В целом должно работать быстрее, это с одной стороны, и несколько улучшу диагностику с другой, хотя объём возвращаемой статистики сократится за счёт исключения малозначимых элементов.
С шарой сделал, хотя как несколько некрасиво, но работает.
Малая скорость распаковки сохранилась и в релизе 1.12.0 - время распаковки NSIS 2,52 /SOLID контейнера FarUE3 x86 (1324 файла, большинство мелкие, суммарный размер 92,3 МБ) на машине с CPU i7-2600/16 Gb DDR3-1600/z68 и с серверными SATA-600 HDD ST32000645NS (1 SATA / 8 потоков - HDD оптимизированы для СУБД, скорость чтения/записи 150/155 МБ/с, время доступа 5,9 мс, 7200 rpm) составило 22 мин 30 сек, плагин ArcLite используя 7z.dll v20.00 Alpha распаковал контейнер за 1,3 сек. Вот скрины снятые в процессе опыта:
Забыл сохранить:) - висел в XnViewMP - скриншот распаковки в ArcLite + 7z.dll v20.00 Alpha:
Кажется, я понял, что в алгоритме от нас убегало, и это то, забышееся решение. :(
Для солида - распаковщик однажды прочтя оглавление в память составляет дерево каталогов с указанием смещений файлов относительно начала архива и затем в ходе распаковки счтитывает их не возвращаясь к задаче построения дерева.
По идее на распаковку должно уйти намного меньше времени и скорость должа приблизится к 7-Zip. Применим?
И как мне думается, лучше держать в ОЗУ плоский (одномерный) список типа списка ls - каталог - файлы и их смещение в архиве - адрес распаковки который обходить последовательно. Это по идее должно намного ускорить работу алгоритма.
Почитай, что такое непрерывный архив и как он распаковывается. Тогда станет понятна проблема. Никакие деревья тут не причем.
Ешё раз гляну, обязательно. Тут я ориентировался по опыту лент - там такой подход значительно ускорял работу НМЛ.
Не надо тут простыни скриншотов делать. Я знаю как оно работает. Будет решение - сообщу.
Добро, я пока пользуюсь 1.11.2 и для распаковки NSIS 3 7-Zip. Это я просто проверял другое ну и увидел.