Несколько FileSystemWatchers хорошая идея?

Question

Я пишу мини-редактор, похожий на Notepad ++ или UltraEdit, который должен отслеживать файлы, которые открывают пользователи - он немного скользкий, но так и должно быть.

Разумно ли использовать несколько экземпляров FileSystemWatcher для мониторинга открытых файлов - опять же, как Notepad ++ или UltraEdit, или есть лучший способ управлять ими?

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

Извините, еще одна вещь, было бы разумнее создать общий FileSystemWatcher для диска и отслеживать его, а затем показывать им только сообщение для перезагрузки файла, как только я знаю, что это правильный файл? Или это отсталый?

Answer 1

Вы не будете сталкиваться с проблемами с несколькими FileSystemWatchers, и на самом деле нет другого способа справиться с этим.

Для повышения производительности обязательно указывайте как можно более узкие фильтры.

Answer 2

FileSystemWatcher имеет недостаток, он блокирует отслеживаемую папку, поэтому, например, если вы просматриваете файл на съемном носителе, он предотвращает «безопасное удаление устройства».

Вы можете попробовать использовать «Уведомления оболочки» через SHChangeNotifyRegister . В этом случае у вас будет одна точка входа для всех изменений (или несколько, если вы хотите), но в этом случае вам потребуется некоторое внутреннее взаимодействие с оболочкой.

Answer 3

Использование нескольких наблюдателей хорошо, если вам нужно. Как говорится в комментарии ShuggyCoUk, вы можете оптимизировать, объединяя средства просмотра файлов в одно, если все ваши файлы находятся в одной папке.

Вероятно, неразумно создавать средство просмотра файлов в гораздо более высокой папке (например, в корне диска), потому что теперь ваш код должен обрабатывать намного больше событий, запускаемых из-за других изменений, происходящих в файловой системе, и довольно легко попасть в переполнение буфера, если ваш код недостаточно быстр для обработки событий.

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

Ваш код выполняется долго (например, часы или дни), когда вы открываете файл, он создает некоторый кусок данных в памяти и создает экземпляр средства просмотра файлов. Затем вы очищаете эти временные данные, но наблюдатель файла все еще там, ЕСЛИ вы повторяете, что несколько раз (и не закрываете файлы, или не забываете распоряжаться наблюдателями), вы просто создали несколько объектов в виртуальной памяти, которые не могут быть перемещены CLR и может потенциально попасть в перегрузку памяти. Обратите внимание, что это не имеет большого значения, если у вас есть несколько наблюдателей, но если вы подозреваете, что можете попасть в сотни или более, остерегайтесь, что это станет серьезной проблемой.

Answer 4

Зависит от вероятных вариантов использования.

Если пользователь собирается открыть несколько файлов в одном и том же каталоге и, вероятно, не будет изменять что-либо еще, один наблюдатель для этого каталога может быть менее обременительным, чем один на файл, если число файлов велико.

Единственный способ, которым вы узнаете, - это сравнительный анализ. Конечно, выполнение по одному на файл значительно упрощает срок службы наблюдателя, так что это должен быть ваш первый подход. Обратите внимание, что наблюдатели запускают свои события в системном пуле потоков, поэтому несколько наблюдателей могут запускать одновременно (что может повлиять на ваш дизайн)

Я бы, конечно, не делал наблюдателя на привод, вы будете прилагать гораздо больше усилий, даже с агрессивной фильтрацией.