One thing that's really educational, and lends some credence to the "registry slowdown" theory, is running RegMon (from
www.sysinternals.com) and then doing some basic Windows operations like launching a file, browsing the start menu, etc.
I have some code that's doing fairly simple MAPI operations to add a contact, and each iteration through my code (which is only a few dozen lines and doesn't contain any registry code) involves around 1500 separate registry accesses.
It would be an interesting project to try to replace the registry with something else (by hooking all the registry calls and directing them to something like an in-memory database) and see what it does to system performance, especially on a mature system with
a large registry.
I just did some cheesy tests of registry performance on two systems I have here. One has my original Windows XP installation from about two years ago (and this has been my main system for the last two years) and the other is a shiny new laptop.
Well, they perform almost identically.. doing simple registry queries, they can each do about 100,000 queries of a fairly deep key in about 4 seconds.
Maybe the registry is getting a bum rap (25k lookups/second doesn't seem too bad.. they're probably cached, but I think most accesses would be). Anyone have any other evidence?
That doesn't seem too bad perf wise...
did you explicitly close the handles between calls, it would be interesting to see if that affects things. It would also be interesting to see what an unmanaged c++ implementation does - 25000 per second seems kinda low...
Actually the registry is interesting in that the performance improvements you get by caching actually hurt scalability, and registry access can really hurt you under sustained load from multiple threads...
That said, it doesn't seem to be causing a slowdown here though as your 2-year old machine is as good as the new one.
Talking of which, is your old machine exhibiting the slowdown problem? Perhaps we could do an online analysis if so? spyware removal followed by defrag maybe might be the next steps...
Thought people might be interested in the ( ongoing ) internal discussion over this. I asked the question about slowdown over time on the internal nt perf tuning alias, and it raised quite a bit of feedback.
The concensus is that filesystem fragmentation seems to be the biggest culprit. One thing that the built in defragmenter won't do is defragment the page file, and over time this can end up with a lot of fragments. Changes to behaviour in XP improved the fragmentation
behavior, but it is still worth considering...
Defragging the page file is interesting. I think the options are:
The freeware offline defragger you listed above is pretty nice. I've got it set to run on every reboot with my work and home machine and have yet to see it cause a problem.
Both are running XP SP2 RC1 at the moment.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.