Thanks for your work. However I want to point out some questions I have about the design and performance (yes, FolderSize slows down my Win2k for several minutes after boot).
It seems that you create new Scanner thread for each Cache object. I suppose that Cache object is created when in Explorer new path needs to be checked (that is not already subpath of path already in cache?). It means that the service may spawn lot of threads. Many threads scanning the same physical disc will result in poor performance, ideally there should be just one scanning worker thread per physical disc.
I did not checked deeply the PerformanceMonitor, but does it exclude performance created by your service?
If you scan folders with large number of files inside, the loop is not suspended during high disc traffic.
My suggestions:
* one idle priority thread scanner per each physical disc
* stop scanning when all explorer windows are minimized/closed
* cache persistence across windows reboots
Thanks for listening, Jan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, you point out a problem with the current design. It is one scanner thread per drive letter, but it should be one scanner thread per physical disk. I rarely use multiple partitions on one disk so I haven't changed this.
The PerformanceMonitor does not exclude performance caused by the service itself. I couldn't think of a good way to detect that. So what happens now is the scanner scans as much as it can, that activity causes it to shut itself off, then it starts again, kind of pulsing on and off. So it could scan faster, but the main effect is achieved, which for me is that a "pulse" does not occur when there is significant other disk activity. I perceive no performance difference in other disk heavy tasks (running Visual Studio and compiling) with the service running or not. Since the performance hit is now negligible, I thought to leave it on all the time, regardless of Explorer windows being closed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Thanks for your work. However I want to point out some questions I have about the design and performance (yes, FolderSize slows down my Win2k for several minutes after boot).
It seems that you create new Scanner thread for each Cache object. I suppose that Cache object is created when in Explorer new path needs to be checked (that is not already subpath of path already in cache?). It means that the service may spawn lot of threads. Many threads scanning the same physical disc will result in poor performance, ideally there should be just one scanning worker thread per physical disc.
I did not checked deeply the PerformanceMonitor, but does it exclude performance created by your service?
If you scan folders with large number of files inside, the loop is not suspended during high disc traffic.
My suggestions:
* one idle priority thread scanner per each physical disc
* stop scanning when all explorer windows are minimized/closed
* cache persistence across windows reboots
Thanks for listening, Jan
Yes, you point out a problem with the current design. It is one scanner thread per drive letter, but it should be one scanner thread per physical disk. I rarely use multiple partitions on one disk so I haven't changed this.
The PerformanceMonitor does not exclude performance caused by the service itself. I couldn't think of a good way to detect that. So what happens now is the scanner scans as much as it can, that activity causes it to shut itself off, then it starts again, kind of pulsing on and off. So it could scan faster, but the main effect is achieved, which for me is that a "pulse" does not occur when there is significant other disk activity. I perceive no performance difference in other disk heavy tasks (running Visual Studio and compiling) with the service running or not. Since the performance hit is now negligible, I thought to leave it on all the time, regardless of Explorer windows being closed.