Registry bloat – a test balloon

We often hear people talking about Windows Registry “bloat” and/or the need to run registry cleaners regularly to “improve registry performance” or something like that. I disagree strongly with that point of view, but until now I have not had actual metrics to build a case on; just an architectural knowledge of Windows gleaned from experience and Windows Internals v4. I still need to buy a copy of Windows Internals v5, which is the latest version.

So over the past few days I have taken the time to write a registry speed tester in c#. It is heavily influenced by a bit of C code Peter Bright wrote in answer to similar questions about registry “bloat”, but frankly I don’t understand C. And I wanted a piece of code I could maintain, as I learned more about what’s going on, and what to test for. So I have ginned up my own roughly equivalent tool.

Now, let’s all be clear on this: I am not an expert coder by any stretch of the imagination. So this is probably not the most efficient code on the street. And it may be unsafe, though I have taken pains to make it as safe as I know how.

Both the compiled executable and the source files are downloadable at the bottom of this article. If you just want a quick peek at the source, have a look these links: RegSpeedTest, CommandArgs. If you feel like living (a tiny bit) dangerously, download the executable and/or source below, try it out, and let me know what you find!

What have I found so far? Well, it’s puzzling: a bigger registry sometimes seems to be a faster registry! Also, after the registry hive grows, it may not shrink immediately after you delete keys. In one of my experiments, the registry did shrink back to its original size, but only a day or two after I grew it. So the registry stays large for awhile, but most of that size is empty space. I don’t think this is a bad thing – my informal results so far show that the larger-but-mostly-empty registry is not appreciably slower. In one case I grew my HKCU hive (ntuser.dat) to well over a half-gigabyte in size. Note that although ntuser.dat was huge, when I extracted all keys from it to a textfile, that file was only 15.6MB in size. I noticed no ill effects from this ‘large-but-mostly-empty’ registry: my system performed as well as it ever has. It made me slightly nervous though, and I did not want to wait for the OS to decide to shrink the registry. So I logged in as a different admin user, and using Previous Versions, restored the old ntuser.dat. I’ll do my tests in virtual machines from now on!

Here’s what RegSpeedTest looks like in action. Sorry, there’s no narration or captions for this video:

In the above video you can see my HKCU hive grows just a little over 1000% (10 times bigger) and yet average key read times increase by less than 8 thousandths of a second (0.00765704 seconds increase to be exact). In quite a few other test runs I have seen the average key read time actually go lower (which means faster key reads) after the registry grew.

A few questions I’ve come up with, as yet unanswered:

• Why do registry reads often seem faster after the registry has grown?
• Does registry read time increase linearly as the registry grows?
• There is variability in the results. What impacts registry performance?
• Once in a great while, I saw registry write times drastically slowed down. What causes this? Is it a frequent occurrence?
• Under what conditions will a ‘large but empty’ registry purge the empty space and shrink to a smaller size on disk and in memory? What triggers the cleanup? Can it be manually triggered?
• How much memory is the registry using, and how can I get a report of that?
• What effect does a large registry (either HKLM or HKCU) have on boot times? What about login times?
• What effect does a large registry have on application performance?

I’m actually a bit surprised at the lack of tools to measure registry performance, and the lack of empirical data supporting all those claims of bloated registry. And my testing so far has revealed a number of counterintuitive things. I would work on it more this weekend, and write out a bunch of observations, but I’m heading off to LinuxFest NorthWest and won’t be back until Monday, so that’s going to have to wait. But I wanted to toss this out there for all six of this blog’s readers to play with, and think about, and discuss in comments below (or email to me, if you like). Have at it!

UPDATE, 2010/12/8 - Drop.IO is shutting down, so I have attached the executable and source files here.