The FSW doesn't sit around waiting for an event from NTFS. There are no such events. So how does the FSW get changes to the file system?
Polling.
Basically, the FSW goes to every directory and subdirectory it's told to watch and grabs the list of files for them. It calls
ReadDirectoryChangesW function (Windows)[
^] on each directory, building a database of what
ReadDirectoryChangesW function (Windows)[
^] changes have happened since the last time each directory was hit by the function call. The FSW doesn't sit around waiting for an event from NTFS. There are no such events. So how does the FSW get these changes?
Polling. Basically, the FSW goes to every directory and subdirectory it's told to watch and grabs the list of files for them. Basically, it calls
ReadDirectoryChangesW function (Windows)[
^] on each directory. The more directories and subdirectories, the longer each polling cycle takes. Once all the directories are processed on one pass, the cycle starts all over again at the top of the directory tree it's told to watch. This is what is taking up so much CPU time.
As it goes through each folder, it starts generating the events your code sees for the changes it finds.
Since you're telling the FSW to watch thousands of folders, it's taking a ton of CPU time polling all of them to get the list of files that changed.
Basically, you're using the FSW for a task it wasn't designed to handle.