How resource-intensive is the FileSystemWatcher?
Tom P.
changes to the file listing while monitoring the directory. I have a
FileSystemWatcher that will raise an event when the file system
changes. The problem with that is it still doesn't give me enough
information to determine what has happened. I also find it goes off
more than once in some conditions and doesn't go off at all in other
conditions, and it goes off early in yet different conditions.
My recourse is to create a FileSystemWatcher for each file in a
directory. That way each file entry can take care of itself when
something happens. But I don't know how resource-intensive that would
be, to have 150 - 300 FileSystemWatchers running at the same time.
I've also thought about making File-based caches for each entry and
then I can rebuild the entry when the cache expires.
Or I could make timers in each FileSystemListViewItem that poll the
file entry and refresh themselves. This would essentially be the same
as the FileSystemWatcher but it might be less resource-intensive.
Any ideas?
Tom P.
Michael B. Trausch
"Tom P." <padill...@gmail.com> wrote:
> I'm writing a file manager and I'm currently trying to deal with
> changes to the file listing while monitoring the directory. I have a
> FileSystemWatcher that will raise an event when the file system
> changes. The problem with that is it still doesn't give me enough
> information to determine what has happened. I also find it goes off
> more than once in some conditions and doesn't go off at all in other
> conditions, and it goes off early in yet different conditions.
As always, testing is going to yield the answer for your situation.
That said, on Mono implements the FileSystemWatcher in several ways:
* Fully in managed code using polling (slow),
* Taking advantage of native APIs for notification (e.g., Linux's
dnotify, which is fast and lightweight).
I don't know what Windows provides, but it probably has some API that
lets you register interest; you can look at a disassembly of .NET's
FileSystemWatcher to see what it does.
> My recourse is to create a FileSystemWatcher for each file in a
> directory. That way each file entry can take care of itself when
> something happens. But I don't know how resource-intensive that would
> be, to have 150 - 300 FileSystemWatchers running at the same time.
Testing will tell you the answer. :-)
> I've also thought about making File-based caches for each entry and
> then I can rebuild the entry when the cache expires.
>
> Or I could make timers in each FileSystemListViewItem that poll the
> file entry and refresh themselves. This would essentially be the same
> as the FileSystemWatcher but it might be less resource-intensive.
>
> Any ideas?
Check it out and experiment locally to see what happens. It's not
definitive, but still useful.
--- Mike
--
W.I.N.D.O.W.S - Will Install Necessary Drivers, Or Won't Start.
Stanimir Stoyanov (C# MVP)
I have not run stress tests on FileSystemWatcher yet but running 150 - 300
instances at the same time would be a very bad design. Instead, you could
look into using as few FileSystemWatcher instances as possible. For example,
one per unique directory (in case you are monitoring multiple directories,
although you did not mention this).
Another useful technique is to incorporate multi-threading in your
application. When you receive a notification from a FileSystemWatcher, you
can start a separate thread to take care of the further processing -- this
way you minimize the possibility of losing notifications that might occur
while the current thread is busy for whatever reason.
Last but not least, optimize your code as much as possible. You can use a
profiler to run tests and see how much the overall performance has decreased
or increased.
HTH,
--
Stanimir Stoyanov
Visual C# MVP
http://stoyanoff.info
"Tom P." <padill...@gmail.com> wrote in message
news:12adf65f-a5ad-4e65...@z7g2000vbh.googlegroups.com...