arclite — работа с архивами на основе 7-Zip

Здесь можно обсудить ваш любимый плагин.
2useven10
Posts: 4039
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 5 times
Been thanked: 185 times

arclite — работа с архивами на основе 7-Zip

Post by 2useven10 »

Тема для обсуждения arclite — нового альтернативного плагина архиватора 7-Zip для Far.
("Старый" плагин 7zipalt обсуждается в прежней теме.)

Внимание:
Начиная с билда 1762 плагин входит в комплект поставки юникодной версии FAR'а, заменяя собой Multiarc.
В arclite не реализованы некоторые функции, присутствовавшие в Multiarc, в частности упаковка в RAR.

Обсуждение: arclite вместо MultiArc в комплекте Far 2











Кодек LZHAM

Polymorph
Posts: 10
Joined: Mon 09 Mar, 2009 09:02
Location: Беларусь

arclite — работа с архивами на основе 7-Zip

Post by Polymorph »

Latest post of the previous page:

Подскажите, пожалуйста, как с использованием arclite получить такой же результат (по времени и степени сжатия), как при запуске 7zip следующей командной строкой:

Code: Select all

7z.exe a ArcName SourceDir -mx=1 -m1=LZMA2
или

Code: Select all

7zG.exe a ArcName SourceDir -mx=1 -m1=LZMA2
Запускаемый таким образом 7zip позволяет весьма быстро получить архив с отличной для такой скорости степенью сжатия. Получить что-то подобное, например, с использованием RAR или ZIP мне не удалось.

Проблема состоит в том, что arclite даже в режиме Fastest тратит на сжатие гораздо больше времени (в моем примере примерно в 8-9 раз), и результат получается с несколько более высокой степенью сжатия, чем у 7zip с указанными выше ключами.

Ситуация воспроизводится на любом компьютере с любой из последних версий Far3/arclite и 7zip по крайней мере в течение последнего года или двух. Я обычно использую версии для x64, но периодически проверяю и на x86. Мой тестовый набор данных — файловая база данных Visual Foxpro (DBF) размером 4-5 Гб, но описанный эффект наблюдается на любых данных достаточно большого размера, чтобы сжатие занимало хотя бы несколько секунд.

Возможно ли получение подобного результата с использованием arclite в принципе? Если нет, то проблема в самом arclite или в используемой библиотеке 7z.dll?

User avatar
John Doe
Бюрократ
Posts: 12814
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 38 times
Been thanked: 286 times

arclite — работа с архивами на основе 7-Zip

Post by John Doe »

Polymorph wrote: проблема в самом arclite или в используемой библиотеке 7z.dll?
Проверьте, заменив дистрибутивную dll на нужную.

Polymorph
Posts: 10
Joined: Mon 09 Mar, 2009 09:02
Location: Беларусь

arclite — работа с архивами на основе 7-Zip

Post by Polymorph »

John Doe wrote:Проверьте, заменив дистрибутивную dll на нужную.
Пробовал. Замена библиотеки ничего не дает. Более того: библиотека из каталога arclite идентична библиотеке из каталога 7zip (бинарное сравнение с использованием fc /b различий не нашло). Я даже поначалу решил, что библиотеку подменил раньше, поэтому заново скачал архив "Far Manager v3.0 build 4242 x64" и перепроверил. Библиотеки идентичны.

Этого достаточно, чтобы сделать достоверный вывод "в пользу вины" arclite? Можно ли это победить?

User avatar
John Doe
Бюрократ
Posts: 12814
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 38 times
Been thanked: 286 times

arclite — работа с архивами на основе 7-Zip

Post by John Doe »

У наблюдаемых вами различий могут быть такие причины:
- arclite поддерживает не все ключи
- у arclite другие умолчания (вы ведь ключами не все параметры задаёте)
Polymorph wrote: Можно ли это победить?
Разумеется.
Проблема в том, что автор плагином не занимается.
Но если вы достоверно выясните источник отличий, и создадите запись на багтрекере, то шансы на исправление увеличатся.

Polymorph
Posts: 10
Joined: Mon 09 Mar, 2009 09:02
Location: Беларусь

arclite — работа с архивами на основе 7-Zip

Post by Polymorph »

John Doe wrote:Но если вы достоверно выясните источник отличий, и создадите запись на багтрекере, то шансы на исправление увеличатся.
Проблема в том, что у меня нет ни знаний, ни опыта для подобной работы с исходным кодом C++.
Но я вас понял, спасибо. Попытаюсь :)

User avatar
John Doe
Бюрократ
Posts: 12814
Joined: Wed 27 Apr, 2005 20:42
Has thanked: 38 times
Been thanked: 286 times

arclite — работа с архивами на основе 7-Zip

Post by John Doe »

Polymorph wrote: у меня нет ни знаний, ни опыта для подобной работы с исходным кодом C++.
Если вы максимально точно укажите в чём проблема, то этого будет достаточно.

Навскидку, указанные вами ключи в справке arclite вообще не нашёл.

User avatar
Wave
Posts: 1772
Joined: Thu 04 Aug, 2005 18:47
Has thanked: 4 times
Been thanked: 16 times

arclite — работа с архивами на основе 7-Zip

Post by Wave »

А я архивирую из пользовательского меню вызывая внешний архиватор (даже не консольный). При этом не блокируется сам ФАР, а окошко архивирования можно свернуть в трей, задать ему приоритеты (фоновый, высокий). Точно так же как для копирования больших файлов или кучи мелких макросом вызываю TeraCopy.
Пользуюсь ФАРом больше 20 лет © собирательный.

Polymorph
Posts: 10
Joined: Mon 09 Mar, 2009 09:02
Location: Беларусь

arclite — работа с архивами на основе 7-Zip

Post by Polymorph »

Выше я приводил следующую командную строку 7zip:

Code: Select all

7z.exe a ArcName SourceDir -mx=1 -m1=LZMA2
Здесь ключ -mx=1 задает уровень сжатия, а ключ -m1=LZMA2 указывает метод сжатия.
Для текущей версии 7zip (9.38 beta) использование -m1=LZMA2 ничего не меняет, поэтому можно обойтись только ключом -mx=1.

У arclite ключу 7zip -mx=N соответствует ключ -l:N. Возможные значения этого ключа: 0, 1, 3, 5, 7, 9. Надо полагать, что меньшее значение ключа должно соответствовать меньшей степени сжатия. Значение 0 должно соответствовать режиму Store (без сжатия).

Попробуем выполнить упаковку с использованием arclite и разных значений ключа из командной строки Far:

Code: Select all

arc:c -t:7z -l:1 -m:lzma2 -s:y ArcName SourceDir
Здесь другие ключи дублируют мои параметры по умолчанию (а также параметры командной строки 7zip с учетом параметров по умолчанию): тип архива 7z, метод сжатия LZMA2, непрерывный архив.

Результаты эксперимента по упаковке данных DBF-таблицы размером 927 191 316 байт:

Code: Select all

ключ -l:0 - размер архива  77151718 байт
ключ -l:1 - размер архива 101203638 байт
ключ -l:3 - размер архива  88333176 байт
ключ -l:5 - размер архива  77151718 байт (совпадение с -l:0)
ключ -l:7 - размер архива  72642576 байт
ключ -l:9 - размер архива  72220344 байт
Время выполнения не контролировалось, но "на глаз" зависимость от полученного размера архива прослеживается.

Полученные результаты для значений 0 и 1 не соответствуют предположению о том, что меньшее значение ключа соответствует меньшей степени сжатия. При этом режим -l:0 не является режимом без сжатия.

Теперь пробуем проделать то же самое с использованием 7zip:

Code: Select all

7z.exe a ArcName SourceDir -mx=1 -m1=LZMA2 -ms=on
Результаты:

Code: Select all

ключ -mx=0 - размер архива 927191562 байт
ключ -mx=1 - размер архива 134254511 байт
ключ -mx=3 - размер архива 118454294 байт
ключ -mx=5 - размер архива  77151718 байт (совпадение с arclite в режимах -l:0 и -l:5)
ключ -mx=7 - размер архива  72220344 байт (совпадение с arclite в режиме -l:9)
ключ -mx=9 - размер архива  72220344 байт (совпадение с arclite в режиме -l:9, а также с-mx=7)
Возможно, есть проблемы с обработкой этого ключа у arclite (почти наверняка ключ -l:0 срабатывает некорректно), или же 7zip обрабатывает это ключ иначе. Возможно, arclite в случае -l:0 вообще не задает значение этого ключа, и тогда библиотека 7zip использует значение по умолчанию -mx=5 (см. размеры архивов; согласно справке 7zip значение по умолчанию для -mx именно 5).
Что происходит с arclite в остальных режимах, предположить пока затруднюсь, но наличие совпадений по размеру архивов, а также тот факт, что в ходе эксперимента изменялись только значение ключей -l:N/-mx=N, скорее всего подтверждает наличие связи с обработкой изменяемых значений ключа.

Интересен результат 7zip в последних двух режимах: либо есть баг, либо повышение уровня сжатия оказалось абсолютно неэффективно в этом конкретном случае.

Проверим на другом примере поведение arclite в режимах -l:0 и -l:5, а также 7zip в режимах -mx=7 и -mx=9.

На этот раз сжимать будем произвольный набор файлов шрифтов, "вырванный" из \Windows\Fonts (исходный размер 113 889 123 байт).

В некотром смысле ни 7zip, ни arclite "не разочаровали".
Результаты 7zip:

Code: Select all

ключ -mx=7 - размер архива  43825730 байт
ключ -mx=9 - размер архива  43825730 байт
То есть предыдущее совпадение в этих режимах скорее всего не случайно, и что-то не так внутри самого 7zip.

Результаты arclite:

Code: Select all

ключ -l:0 - размер архива  44555854 байт
ключ -l:5 - размер архива  44555854 байт
Для очистки совести также выполним бинарное сравнение архивов, размеры которых совпадают (с использованием fc /b): различий не найдено.
Таким образом, совпадения не случайны.

Polymorph
Posts: 10
Joined: Mon 09 Mar, 2009 09:02
Location: Беларусь

arclite — работа с архивами на основе 7-Zip

Post by Polymorph »

Обнаружились трудности с воспроизведением проблемы. Ситуация уточняется.

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

arclite — работа с архивами на основе 7-Zip

Post by ccaid »

имеет смысл проверить поведение arclite при управлении через диалог
Фар делают добрые люди

Karagy
Posts: 57
Joined: Tue 02 May, 2006 08:43
Location: Питер
Been thanked: 3 times

arclite — работа с архивами на основе 7-Zip

Post by Karagy »

Я проверил гипотезу разных частот рабочих тредов. Увы, в момент сжатия частота сжимающих тредов (в гуёвом 7zip это один единственный тред дочернего процесса порождаемого для сжатия; в фаре - это (вроде-бы) головной тред фара в котором молотит арклайт) - примерно одинакова и равна примерно 80 герц на моём компе (WinXp x32, Far 3.0 build 4040 x86, CPU 1 core enabled).

Почему я считаю что это могло иметь значение:

Karagy
Posts: 57
Joined: Tue 02 May, 2006 08:43
Location: Питер
Been thanked: 3 times

arclite — работа с архивами на основе 7-Zip

Post by Karagy »

В догонку, всё мной изложеное выше приведено для одноядерного процессора.
Тем временем, в инетах пишут, что ключ -mmt в 7zip, отвечающий за мультитредный режим, может быть включен по умолчанию. На двух-ядерном ведре с Win7 x64, FAR 3.0 build 4242 x64, я наблюдаю два заспавненых и активно работающих треда от арклайта при сжатии файла.
Polymorph, интересно сколько тредов сжимают в гуёвом 7zip и в арклайте на вашей машине.

Polymorph
Posts: 10
Joined: Mon 09 Mar, 2009 09:02
Location: Беларусь

arclite — работа с архивами на основе 7-Zip

Post by Polymorph »

ccaid wrote:имеет смысл проверить поведение arclite при управлении через диалог
Проверим (см. ниже).
Polymorph wrote:Обнаружились трудности с воспроизведением проблемы.
Все замечательно воспроизводится. Фокус был в отличиях GUI и командной строки.
Karagy wrote:сколько тредов сжимают в гуёвом 7zip и в арклайте на вашей машине
Вы знаете, я не сумел это посмотреть. Начал с ProcessExplorer, закончил с упомянутым вами ProcessHacker, но увидеть количество тредов и частоты не сумел (содержимое вкладки Threads как-то слабо коррелировало с тем, что вы рассказали). Не подскажете, куда/как смотреть?
Под частотой треда имеется в виду величина, обратная периодичности, с которой планировщик ОС выделяет треду процессорные ресурсы?

Ниже - результаты новых экспериментов.

Конфигурация и подготовка:


Эксперимент №1


Эксперимент №2


Предварительные выводы №1:
1. Режим Store у arclite из командной строки не сработал. Результат в режиме -l:0 аналогичен результату в режиме -l:5.
2. Отличий между режимами Maximum (-l:7) и Ultra (-l:9) нет.

Эксперимент №3


Предварительные выводы №2:
1. Режим Store у оригинального 7zip тоже не сработал, что настораживает, но дает пищу для размышлений.
2. Отличий между режимами Maximum (-mx=7) и Ultra (-mx=9) тоже нет.
3. Уровни сжатия у arclite и 7zip в режимах Fastest (1) и Fast (3) отличаются: arclite сжимает сильнее, но за счет бОльших затрат времени.

Эксперимент №4


Предварительные выводы №3:
1. У arclite режим Store из командной строки все равно не сработал.
2. У 7zip режим Store сработал на ура. Значит, при наличии "лишних" параметров в командной строке приоритет отдается им.

В сухом остатке:
1. Режимы Fastest и Fast arclite обрабатывает как-то иначе, чем оригинальный 7zip (и через GUI, и через командную строку). Из-за этого указанные режимы гораздо менее удобны (особенно Fastest), т.к. на сжатие тратится слишком много времени.
2. С остальными режимами все в порядке. Оригинальному 7zip соответствуют.
3. Для режима Store в командную строку 7zip не стоит передавать "лишние" параметры, иначе содержимое может сжиматься.
4. Получить режим Store из командной строки для arclite не удалось. Я что-то сделал не так?
5. Частоты тредов не повлияли бы на размеры архивов, только на время сжатия (и то не очевидным образом). Но информация все равно любопытная. Нужно присмотреться.

Главная проблема режима Fastest, конечно, во времени. Но при различных размерах архивов очевидно, что используется различная логика сжатия. Тогда первопричина затрат времени скорее всего будет именно в этом.

ЗЫ. Проверить на стабильной сборке x86, а также на ночных сборках пока не получилось (нехватка времени). Проверю позже. Но, поскольку описанную ситуацию с режимом Fastest я наблюдаю со времени появления Far3 с arclite'ом в комплекте, независимо от разрядности сборки, используемой ОС или т.п., результаты скорее всего будут аналогичными.

ccaid
Posts: 846
Joined: Fri 12 Jun, 2009 16:04
Has thanked: 17 times
Been thanked: 5 times

arclite — работа с архивами на основе 7-Zip

Post by ccaid »

как известно, уровень сжатия — это просто предопределенный набор значений низкоуровневых параметров сжатия. и в документации эти параметры и значения можно найти. 7zip предоставляет возможность поуправлять этими параметрами напрямую. arclite, с помощью ключа -adv, тоже — согласно хелпу. насколько соответствует реальности, я не знаю.
разумеется, даже если это получится, это будет workaround. полагаю, автор arclite просто настроил под себя уровни сжатия. вполне можно завести issue на мантис на эту тему.
Фар делают добрые люди

alexmitin
Posts: 50
Joined: Tue 17 Feb, 2009 08:37
Been thanked: 1 time

arclite — работа с архивами на основе 7-Zip

Post by alexmitin »

В arclite поломался просмотр и распаковка из rpm файлов.

Не работает:

Code: Select all

Far Manager, version 3.0 (build 4326) x86
arclite.dll 1.6.7.0
7z.dll 9.35.0.0
В этой версии просмотр rpm и распаковка работает:

Code: Select all

Far Manager, version 2.1 (build 1807 bis23) x86
arclite.dll 1.4.10.0
7z.dll 9.20.0.0
Я пробовал скопировать файлы plugins/ArcLite/7z* из Far2 в Far3, но результат тот же.

Например, на этом файле:
http://yum.postgresql.org/9.4/redhat/rh ... noarch.rpm

1) На файле "pgdg-centos94-9.4-1.noarch.rpm" в панели FAR2 нажимаем Enter.
2) Затем на "pgdg-centos94-9.4-1.noarch" нажимаем Enter еще раз.
3) Нажимаем на "." Enter, затем на "etc", затем на "pki", затем на "rpm-gpg".
4) Используем F3 для просмотра или F5 для распаковки файла "RPM-GPG-KEY-PGDG-94"

В FAR3 на шаге 2 открывается диалог Windows:

Code: Select all

Windows can't open this file:
File: pgdg-centos94-9.4-1.noarch

To open this file, Windows needs to know what program you want to use to
open it. Windows can go online to look it up automatically, or you can manually
select from a list of programs that are installed on your computer.

What do you want to do?
* Use the Web service to find the correct program
* Select a program from a list of installed programs

User avatar
zg
zero-gravity
Posts: 5816
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 147 times
Contact:

arclite — работа с архивами на основе 7-Zip

Post by zg »

alexmitin wrote:В arclite поломался просмотр и распаковка из rpm файлов.
всё прекрасно работает.
alexmitin wrote:В FAR3 на шаге 2 открывается диалог Windows:
либо жмите pgdn, либо зайдите в настройки и настройте плагин соответствующим образом.

Post Reply

Return to “Обсуждение плагинов”