I developed a Windows software about an year ago. Part of it was to monitor few configuration files for manual changes by user and if any of these change restart a particular service.
So, I used the simplest approach. I load them as a string in memory and after few seconds, I read the latest file and compare it with the one in memory. Since, the files are very small (less than 500KB), the program doesn’t consume much memory.
I am using that application since it is developed and have not experienced any performance problem due to that. But, few days ago I noticed that the program ranks at highest for I/O Read Bytes in task manager. After few hours of uptime of PC, the I/O Read Bytes by this program become significant higher than the rest of processes.
So, My question is should I worry about high value of I/O Read Bytes. Is this have some downside effect (maybe on Hard Disk) that I am missing. Is implementing the functionality of monitoring file changes using Windows API have some benefits that are worth the effort required to implement it?
I’m not surprised, every few seconds you open a file, and read the contents. Repeat forever keeping your disk from sleeping.
The file notification APIs are very easy to use, make the call to set things up and then simply wait for your callback to be called. When you get the callback, you know something has modified the file, so then you read the contents as you do now. The only thing you have to lose is the busy-polling!
1
If you only worry about your program being the greatest I/O user: don’t. If you changed it, then by definition, something else would become the greatest I/O user on the system, so you gain nothing.
If you have something else to point to a problem with resource usage – users complaining, jobs delayed, etc. then you could check out whether rewriting is worthwhile. But occasionally reading a small file, and always the same at that, is unlikely to put a large strain on a full-fledged Windows installation.
1
It might keep your disk from sleeping, which is especially bad on a laptop. However, I don’t know how good the file caching is on Windows. On Linux, those files would be cached in memory if unchanged, and your reads would most likely come from memory, not the disk itself. I assume Windows is similar.
The advantages are that you consume practically zero memory and CPU time when the files aren’t changing, which is most of the time, and when it does change, there’s a very short latency before your program finds out about it. You know in milliseconds instead of seconds. You don’t have to worry about how long you wait in between checks, in order to balance latency with resource usage.
The file monitoring APIs are not that difficult. I almost never program for Windows, and I once implemented a feature using them in a couple hours. Just stop thinking about it and give it a try. If you don’t like the result, that’s what version control is for. Just make sure to try it with different editors, because some do a rename from a temporary file rather than modifying the file in place.
Also something you may not have considered, is reading config files this way makes it difficult for users to control when their changes are applied. If they have a large config edit to do, they can’t save it when they are partially through, unless they use a different file name. That’s why most services only read the config on a restart or signal.
1