Polling and MSN Desktop Search
One thing I do regularly is run Filemon and Regmon to identify poorly written software. In the context of these tools a poorly written application is one that polls (repeatedly queries) the file system or Registry for changes. Polling is undesirable because it degrades performance. A thread that polls sleeps for the polling intervals, wakes up to perform its queries, and then goes back to sleep.
When the thread wakes up and the kernel schedules it the system must context-switch away from potentially useful work to the polling thread. The context switch results in an invalidation of the translation lookaside buffer (TLB – a high-speed cache of virtual to physical memory translations) of the processor and consumption of CPU resources as the thread executes. In addition, the thread references code and data as it executes, which the memory manager must make resident in physical memory, thus consuming memory resources.
If polling is so bad, what’s the alternative? If an application wants to respond in a timely manner to Registry changes it can use the RegNotifyChangeKeyValue API, and for file system changes it can use ReadDirectoryChangesW or FindFirstChangeNotification.
All that said, there are still lots of applications out there, including Microsoft applications, that poll. I suggest you run Filemon and Regmon on your own systems to see what kinds of badly-behaved software you have. Some of the most egregious offenders are the Windows services associated with major antivirus products.
When I ran Regmon yesterday the trace showed that MSN Desktop Search polls. This Regmon output shows msnlAdmin.exe, the MSN Desktop Search administrator process, repeatedly querying the current computer name value (about 4 times a second):
When I saw this I suspected that msnlAdmin.exe wasn’t polling the value directly, but instead repeatedly executing an API that reads the value. I attached to the process using Windbg (from Microsoft’s Debugging Tools for Windows), set a breakpoint on NtQueryValueKey (the native API invoked by Windows API Registry queries), and when it hit looked at the stack:
So msnlAdmin.exe is actually querying the name of the computer, which underneath results in a Registry API. The developer probably assumed that the value was cached, but since its not they should cache it. Why msnlAdmin.exe is constantly running I can’t say, however.
Originally by Mark Russinovich on 3/25/2005 12:23:00 PM
Migrated from original Sysinternals.com/Blog
# re: Polling and MSN Desktop Search
Hehe, you should checkout the MS Anti Spyware program... it's worse than that!
3/25/2005 5:05:00 PM by Wells
# re: Polling and MSN Desktop Search
I use Copernic Desktop Search and it works quite good. Last 1.5beta release also allows to write third-party addins , just like IFilters. The only thing that it (and most other desktop engines) lacks is a feature to search with non-English morphology.
3/26/2005 10:56:00 PM by Ivan
# re: Polling and MSN Desktop Search
Mark, just one question off the topic: I am curious about these additional buttons in the upper right corner - what are they for?
BTW: Don't I pool even if I use ReadDirectoryChangesW or FindFirstChangeNotification?
3/28/2005 3:21:00 PM by Stan
# re: Polling and MSN Desktop Search
The buttons look like those used for multi-desktop/monitor setups, so you can send that window to the next monitor.
3/29/2005 12:47:00 PM by Wells
# re: Polling and MSN Desktop Search
This is a great tip! I've written NT services before that polled or used FindFirstChangeNotification, but there's no excuse for the polling that Skype does when it's offline!
Cheers,
Nick.
3/29/2005 8:45:00 PM by sicklittlemonkey
# re: Polling and MSN Desktop Search
Thanks for tracking this down. We really do appreciate people looking at these things (seriously!). While we also spend time looking at what's really going on under the covers in order to improve perf, we're only human and can only look at so much in the time available. And, for the beta, we didn't have much time available for this type of investigation (which is one reason we decided to make it a beta! :-) )
In this particular case, though, since the beta we've quit using the CIState API (for some unrelated reasons), hence we aren't calling GetComputerName at all. In addition, we're being a heck of a lot smarter about what we do wrt polling vs events and, in those cases where we're forced to poll, we've taken some hard looks at how to minimize what we do there.
You should see this with the next public release of Desktop Search.
Definitely post any other "doh!" things you might find. Again, we (MSN Desktop Search devs) really do appreciate the feedback and do our best to address these things.
Thanks.
3/30/2005 10:01:00 AM by Dave S [msft]
# re: Polling and MSN Desktop Search
Mark,
I'm using your utilities since early stages, and I wonder why you never released something to clean Windows Registry: what do you think about, is a Registry cleaner really needed?
3/30/2005 4:50:00 PM by matro
# re: Polling and MSN Desktop Search
Re: Dave S [msft]
Thanks for the comment, Dave. I'm looking forward to the next release. What's the best way to report other bugs that I've run into?
Re: Matro
No, Registry cleaning is uninteresting to me because it involves a thorough investigation of applications and their use of Registry data. If you're too aggressive in the cleaning you end up with broken apps. That, and the fact that Registry cruft sitting around won't be a significant contributor to Registry size or performance issues, is why I don't trust my system to Registry cleaners.
4/4/2005 2:02:00 PM by Mark Russinovich
# re: Polling and MSN Desktop Search
Fascinating stuff. I'm new to Regmon - so apologies if this is obvious (but I Googled briefly and could find nothing relevant) but on my PC (XP SP2), services.exe polls the registry about 500 times per second - i.e. I get around 5000 entries in Regmon if I run it for 10 seconds. Is this normal?
4/5/2005 7:33:00 AM by Anonymous
# re: Polling and MSN Desktop Search
I sure hope the M$ people read your blog, as usual, YOU DA MAN!
4/28/2005 8:46:00 AM by Anonymous