Hекоторые недоработки WinRAR
Sergey Nikiforov
1) Кнопка "Background" - это здорово. Hо при завершении операции окно WinRAR
принудительно захватывает фокус. Что чертовски мешает, когда действительно
активно работаешь за машиной (или даже просто смотришь фильм) и выясняешь, что
компьютер неожиданно переключился на другую задачу, последствия - от
необходимости перетасовывать окна на экране до "случайно нажал не ту кнопку и
стёр всё нафиг".
Было бы неплохо сделать возможность при завершении фоновой операции не вылезать
в foreground, а рисовать другую (например, "мигающую") иконку в трее.
Опционально, естественно.
2) Сейчас WinRAR при работе с диском использует механизмы кэширования ОС. То,
что это отрицательно влияет на скорость сжатия большого количества мелких
файлов (из-за отсутствия prefetch в этом случае), уже обсуждалось. Есть гораздо
более серьёзный недостаток этой схемы, который проявляется в основном при
работе с большими объёмами информации. Пример: быстрая машина с 2 GB RAM, архив
размером порядка 4 GB. Собственно, при "обычном" сжатии особых проблем нет
(хотя я бы не отказался от мЕньшей фрагментации создаваемого архива). А вот при
менее "процессороёмких" операциях (создание архивов без сжатия, тестирование и
особенно добавление recovery record) получается следующая картина: WinRAR,
читающий/пишущий многие гигабайты, успешно "вымывает" из физической памяти
код/данные запущенных приложений (в том числе свои собственные, ОС и shell'а) и
"полезный" file cache и забивает её кусками обрабатываемых данных (что не имеет
смысла из-за "линейности" операций и недостаточности объёма физической памяти
для кэширования всего объёма обрабатываемых данных). Результат предсказуем:
вместо выполнения операции за единицы минут (близко к скорости линейного
чтения/записи HDD) вся система (а не только WinRAR) впадает в ступор на десятки
минут из-за активного swapping (имеем случайный доступ к HDD со всеми
вытекающими гадостями в случае механических накопителей). Hастолько, что даже
до WinRAR'овской кнопки "Pause" бывает не добраться.
Разумеется, WinRAR - далеко не единственное приложение, имеющее такую проблему.
Hо он же - одно из немногих приложений, используемых обычными пользователей для
работы с большими объёмами данных, так что хотелось бы видеть в нём решение -
опциональную возможность использования небуферизованного ввода/вывода
(возможно, с prefetch или даже более сложными методами кэширования, но с
ограничением объёма этого кэша, который, естественно, должен быть "заперт" в
физической памяти, если операция не "поставлена на паузу"). Судя по моему опыту
работы с другими приложениями - это позволит сделать возможность
_действительно_ фоновой работы WinRAR.
Мнения?
WBR, Sergey
Eugene Roshal
SN> Разумеется, WinRAR - далеко не единственное приложение, имеющее такую
SN> проблему. Hо он же - одно из немногих приложений, используемых обычными
SN> пользователей для работы с большими объёмами данных, так что хотелось бы
SN> видеть в нём решение - опциональную возможность использования
SN> небуферизованного ввода/вывода (возможно, с prefetch или даже более
Сейчас проверил флаг FILE_FLAG_WRITE_THROUGH функции CreateFile, с ним кэш все
равно растет как и без него. А FILE_FLAG_NO_BUFFERING так просто не
использовать. Там надо делать посекторное выравнивание для размеров и адресов.
Кроме того, возможно придется какой-нибудь свой кэш реализовывать, а это
довольно объемная задача.
SN> операция не "поставлена на паузу"). Судя по моему опыту работы с другими
SN> приложениями - это позволит сделать возможность _действительно_ фоновой
SN> работы WinRAR.
Насчет фоновой работы - в висте появился новый флаг
PROCESS_MODE_BACKGROUND_BEGIN для SetPriorityClass. Надо будет его
попробовать. Он должен снизить приоритет и для операций ввода/вывода.
Eugene
Sergey Nikiforov
31 Jul 2007 10:28, Eugene Roshal wrote to Sergey Nikiforov:
ER> FILE_FLAG_NO_BUFFERING так просто не использовать. Там надо делать
ER> посекторное выравнивание для размеров и адресов.
Да, я в курсе. Hо ИМХО оно того стоит.
ER> Кроме того, возможно придется какой-нибудь свой кэш реализовывать, а
ER> это довольно объемная задача.
А оно точно требуется? Hасколько я понимаю - дисковые операции получаются
практически линейными, небольшого read ahead при чтении и отложенной
последовательной записи должно быть вполне достаточно. Для начала - в пределах
файла, это не даст прироста скорости сжатия большого количества мелких файлов,
но хотя бы не будет ставить систему в ступор.
ER> Hасчет фоновой работы - в висте появился новый флаг
ER> PROCESS_MODE_BACKGROUND_BEGIN для SetPriorityClass. Hадо будет его
ER> попробовать. Он должен снизить приоритет и для операций ввода/вывода.
Честно говоря, сомневаюсь, что оно хоть как-то повлияет на поведение file
cache.
Кстати, о птичках. Когда-то давно здесь обсуждалась проблема совместимости с
Outpost Firewall, и, если мне не сильно изменяет мой склероз, упоминалось о
том, что WinRAR очень часто вызывает CreateThread. Это точно хорошая идея?
Рекомендации Microsoft - создать набор thread и скармливать им работу, не более
одной активной thread на процессор. Даже специальный thread pool API для
облегчения реализации подобного существует. Я сам не тестировал, но по идее
отказ от overhead создания/уничтожения threads действительно должен позитивно
сказаться на производительности multithread сжатия.
Впрочем, лично меня гораздо больше волнуют проблемы с file cache.
P. S. Предложение о менее деструктивном вылезании в foreground принято?
WBR, Sergey
Eugene Plugin
Помню Воскресенье 29 Июля 2007 года (приблизительно в 23:05:26)
тип _#Sergey Nikiforov_# нарисовал к _/#Eugene Roshal_/# по поводу
SN> 1) Кнопка "Background" - это здорово. Hо при завершении операции окно
SN> WinRAR принудительно захватывает фокус. Что чертовски мешает, когда
SN> действительно активно работаешь за машиной (или даже просто смотришь
SN> фильм) и выясняешь, что компьютер неожиданно переключился на другую
SN> задачу, последствия - от необходимости перетасовывать окна на экране
SN> до "случайно нажал не ту кнопку и стёр всё нафиг".
SN> Было бы неплохо сделать возможность при завершении фоновой операции не
SN> вылезать в foreground, а рисовать другую (например, "мигающую") иконку
SN> в трее. Опционально, естественно.
Что интеpесно, если аpхивиpовать не чеpез основное окно, а чеpез контекстное
меню (пpавая кнопка мыши на нужном файле/папке - Winrar - Добавить в аpхив), то
после окончания аpхивиpования (не важно в каком pежиме - фоновом или нет)
вообще ничего не выскакивает, из-за чего пеpиодически забываешь, что ставил
что-то аpхивиpовать и куда собственно этот аpхив "улетел". :)
Так что действительно нужна какая-то напоминалка для всех pежимов
(отключаемая, пpичем желательно в виде галочки на окне "Паpаметpы
аpхивиpования" пеpед началом аpхивации, и в окне "Паpаметpы опеpации", то есть
когда сжатие уже пpоисходит) с указанием какой аpхив создан и по какому пути,
но без выскакивания на пеpвый план (напpимеp, мигнуть в тpее паpу pаз и
оставить там окно с инфоpмацией и кнопкой "ОК"; пpи этом, если имеется очеpедь
из аpхивов - она не должна висеть в ожидании нажатия "ОК", а пpодолжать pаботу;
если очеpедь большая - больше 10, напpимеp, "ОК" лучше закpывать в поpядке
очеpедности, чтобы у забывших отключить вся pабочая область ими не покpылась
:).
2ER: ИМХО, задачу я достаточно подpобно изложил, ждем pеализации. :-)
*FP_Prognoz(гав)List.Ru*
С уважением, /Eugene/ от Вторник 31 Июля 2007 года.
... _/*От женщины никогда не знаешь, что ожидать - девочку или мальчика_/*.
Eugene Roshal
ER>> Кроме того, возможно придется какой-нибудь свой кэш реализовывать, а
ER>> это довольно объемная задача.
SN> А оно точно требуется? Hасколько я понимаю - дисковые операции получаются
SN> практически линейными, небольшого read ahead при чтении и отложенной
RAR после упаковки каждого файла возвращается к его заголовку для записи CRC32
и упакованного размера.
ER>> Hасчет фоновой работы - в висте появился новый флаг
ER>> PROCESS_MODE_BACKGROUND_BEGIN для SetPriorityClass. Hадо будет его
ER>> попробовать. Он должен снизить приоритет и для операций ввода/вывода.
SN> Честно говоря, сомневаюсь, что оно хоть как-то повлияет на поведение file
SN> cache.
Да, сейчас посмотрел, похоже, не влияет. Но, судя по результатам этого моего
теста, в Висте несколько изменили алгоритм кэширования. По крайней мере занять
кэшем больше примерно 2/3 памяти WinRAR'у при упаковке в Висте не удалось.
Причем это значение может быть и меньше в зависимости от наличия других
активных приложений (я запускал FAR, и размер кэша уменьшался). В XP же легко
занимается ~97%. Кроме того, хоть PROCESS_MODE_BACKGROUND_BEGIN и не влияет на
размер кэша, он влияет на приоритет дисковых операций, что тоже дает свой
заметный эффект. По моим впечатлениям проблема с влиянием фонового WinRAR на
другие приложения в Висте при использовании PROCESS_MODE_BACKGROUND_BEGIN
сведена к минимуму.
SN> существует. Я сам не тестировал, но по идее отказ от overhead
SN> создания/уничтожения threads действительно должен позитивно сказаться на
SN> производительности multithread сжатия.
Я при разработке SMP кода сравнивал производительность реализаций с thread
pool и нынешней. Разница была в пределах погрешности измерения, так что я
выбрал более простой нынешний вариант.
SN> P. S. Предложение о менее деструктивном вылезании в foreground принято?
Я его принял к сведению, но пока не определился, что с ним делать. Чем дальше,
тем меньше мне хочется добавлять новые интерфейсные опции, так как настройки и
так уже перегружены опциями. Мне проще изменить поведение по умолчанию без
опций, но я не уверен, всем ли это понравится. И добавлять еще одну ненужную
опцию тоже не хочется.
Eugene
Sergey Nikiforov
01 Aug 2007 09:26, Eugene Roshal wrote to Sergey Nikiforov:
ER> Hо, судя по результатам этого моего теста, в Висте несколько изменили
ER> алгоритм кэширования. По крайней мере занять кэшем больше примерно 2/3
ER> памяти WinRAR'у при упаковке в Висте не удалось.
Я в основном в Vista и тестировал. Полный ступор на добавлении recovery record.
ER> По моим впечатлениям проблема с влиянием фонового WinRAR на другие
ER> приложения в Висте при использовании PROCESS_MODE_BACKGROUND_BEGIN
ER> сведена к минимуму.
Хотелось бы пощупать такую сборку.
ER> Я при разработке SMP кода сравнивал производительность реализаций с
ER> thread pool и нынешней. Разница была в пределах погрешности измерения,
ER> так что я выбрал более простой нынешний вариант.
Кстати, в Vista сделали новый thread pool API. Может, что-то и изменилось. Если
интересно.
А affinity на разные процессоры для разных threads расставляется? По идее это
должно улучшать эффективность использования кэша.
Hо ИМХО сначала всё-таки стоит заняться вводом/выводом.
WBR, Sergey
Eugene Roshal
ER>> По моим впечатлениям проблема с влиянием фонового WinRAR на другие
ER>> приложения в Висте при использовании PROCESS_MODE_BACKGROUND_BEGIN
ER>> сведена к минимуму.
SN> Хотелось бы пощупать такую сборку.
Напиши мне на email куда послать winrar.exe.
ER>> Я при разработке SMP кода сравнивал производительность реализаций с
ER>> thread pool и нынешней. Разница была в пределах погрешности измерения,
ER>> так что я выбрал более простой нынешний вариант.
SN> Кстати, в Vista сделали новый thread pool API. Может, что-то и
SN> изменилось. Если интересно.
Я thread pool API не пользовался, сделал свою реализацию.
SN> А affinity на разные процессоры для разных threads расставляется? По идее
SN> это должно улучшать эффективность использования кэша.
Тоже проверял, заметной разницы не увидел.
Eugene
Xander Olegovich Fedorov
> Я его принял к сведению, но пока не определился, что с ним делать. Чем дальше,
> тем меньше мне хочется добавлять новые интерфейсные опции, так как настройки и
> так уже перегружены опциями. Мне проще изменить поведение по умолчанию без
> опций, но я не уверен, всем ли это понравится. И добавлять еще одну ненужную
> опцию тоже не хочется.
Тогда надо пойти по накатанному уже пути - тонкие и лишние настройки писать
только в файл конфигурации (в простом текстовом формате, удобном для
редактирования Notepad.exe). И те, кому что-то очень не понравится смогут
пользуясь FAQ и комментариями в самом файле конфигурации поправить
что им было нужно.
xof