Mulitple FileSystemWatchers une bonne idée?

Question

J'écris un mini composant d'éditeur qui ressemble beaucoup à Notepad ++ ou UltraEdit qui a besoin de surveiller les fichiers ouverts par les utilisateurs - c'est un peu visqueux, mais c'est comme ça que ça doit être.

Est-il sage d'utiliser plusieurs instances de FileSystemWatcher pour surveiller les fichiers ouverts - à nouveau comme Notepad ++ ou UltraEdit ou est-il une meilleure façon de gérer ces?

Ils seront correctement éliminés une fois le document fermé. Désolé, une autre chose, serait-il plus sage de créer un FileSystemWatcher générique pour le lecteur et de le surveiller, puis de lui montrer un message pour recharger le fichier une fois que je connais son bon fichier? Ou est-ce remis en question?

Answer 1

Tu ne vas pas rencontrer des problèmes avec plusieurs FileSystemWatchers, et il n'y a vraiment pas d'autre moyen de retirer ceci.

Pour des performances, juste être sûr de spécifier des filtres aussi étroites que vous pouvez sortir avec.

Answer 2

Cela dépend des cas d'utilisation probables.

Si un utilisateur va ouvrir plusieurs fichiers dans le même répertoire et probablement ne rien modifier, un seul observateur pour ce répertoire peut être moins onéreux qu'un fichier par fichier si le nombre de fichiers est important.

La seule façon de le savoir est de faire un benchmarking. Certainement faire un par fichier rend la vie de l'observateur beaucoup plus simple, ce qui devrait être votre première approche. Notez que les observateurs lancent leurs événements sur un pool de threads système, de sorte que plusieurs observateurs peuvent tirer en même temps (quelque chose qui peut influencer votre conception)

Je ne ferais certainement pas un observateur par lecteur, vous provoquerez beaucoup plus effort de cette façon, même avec un filtrage agressif.

Answer 3

FileSystemWatcher ont un inconvénient, il verrouille le dossier surveillé, ainsi, par exemple, si vous regardez le fichier sur le stockage amovible, il empêche « l'enlèvement de l'appareil en toute sécurité ».

Vous pouvez essayer d'utiliser Notifications Shell via SHChangeNotifyRegister. Dans ce cas, vous aurez un point d'entrée pour tous les changements (ou plusieurs si vous le souhaitez), mais dans ce cas vous aurez besoin d'un shell natif interop.

Answer 4

L'utilisation de plusieurs observateurs est très bien si vous devez le faire. Comme le dit le commentaire ShuggyCoUk, vous pouvez optimiser en combinant les surveillants de fichiers en un si tous vos fichiers sont dans le même dossier. Il est probablement imprudent de créer un observateur de fichiers sur un dossier beaucoup plus élevé (par exemple la racine du lecteur), car maintenant votre code doit gérer beaucoup plus d'événements tirant d'autres changements dans le système de fichiers, et c'est assez facile entrer en débordement de tampon si votre code n'est pas assez rapide pour gérer les événements.

Un autre argument pour moins watcher fichier, un FileSystemWatcher est un objet natif, et les broches mémoire. Ainsi, en fonction de la durée de vie et de la taille de votre application, vous risquez de rencontrer des problèmes de fragmentation de mémoire. Voici comment:

Votre code s'exécute pendant une longue période (par exemple, des heures ou des jours) à chaque ouverture d'un fichier. données en mémoire et instancie un observateur de fichier. Vous nettoyez ensuite ces données temporaires mais l'observateur de fichier est toujours là, SI vous répétez plusieurs fois (et ne fermez pas les fichiers, ou oubliez de disposer les observateurs) vous venez de créer plusieurs objets dans la mémoire virtuelle qui ne peuvent pas être déplacés par le CLR, et peut potentiellement entrer dans la congestion de la mémoire.Notez que ce n'est pas une grosse affaire si vous avez quelques observateurs, mais si vous pensez que vous pourriez entrer dans les centaines ou plus, méfiez-vous que cela va devenir un problème majeur.