RegBench - New utiliity to benchmark your system registry performance

[Jeremy Collake]

Ever want to know if cleaning or defragmenting your registry really makes a difference in its performance?

RegBench is a small utility that benchmarks your system registry. It outputs to XML and uses a display template to allow for viewing of the results within your web browser. It is a console mode utility, but a GUI front-end will be added if this product turns out to be popular.

I've had this code mostly done for some time now. I decided to put a little polish on it today so that I could release an early alpha version. It is still far from complete, and I particularly need to work on adding more benchmark types and a better XSLT output format. This utility will be FREE for home and academic use.

Here is v0.1 alpha: http://www.bitsum.com/files/regbench.zip

Please, give feedback. If users are interested in this, I will continue development. The code base is very clean and ready to do much more extensive benchmarking.

[Hotrod]

Yesss!!! I am verry interested in this. I would however prefer the GUI to XML as some of my older PC's have some serious limitations. I will give it a whirl when i get home from work and get back to you with some constructive (hopefully ) input.

[Jeremy Collake]

Thanks. It is kind of experimental.

I'm honestly not sure if it will be useful or not. I think what it may show, more than anything, is that except in extreme cases, no registry cleaning or defragmenting makes much of a difference. Or maybe it will show just the opposite. That's what we'll find out.

I may need to add more algorithms and/or adjust the number of iterations .. the core is so ready, so whatever needs to be done I'll do.

I do intend to write a GUI, everything needs a GUI now-a-days. In its test stage, I just want to see how much interest there is, and if there is ever a real change in registry performance.

[Jeremy Collake]

I'm also considering making this open source ...

[Hotrod]

Windows XP Home Edition SP3, Celeron 2.00 Ghz, 384 RAM

[Jeremy Collake]

Oh, thanks. That's a manifest error. I'll fix it and upload a new build in just a minute.

[Jeremy Collake]

Ok, done. Please let me know if you have continued problems.

[Hotrod]

Nope, Do I need to have some prerequisite installed? 

[Jeremy Collake]

Yes, you need the MSVC runtime libraries installed. I will do a static link and re-upload. Update: Done -- you no longer need them.

This is early alpha, I hadn't packaged it at all for general consumption. It should run ok now without any pre-requisites though.

[Hotrod]

That did the trick.  Thank you for the extra effort. I can't wait for the GUI as the text in my browser from the xml is a tad bit HUGE.  A good feature would be to be able to save before and after measurements on a single form. The basic function seems to work well enough. Now if I only knew enough about registries to know what it all means. I assume shorter times are better and I should see some longer access times when the registry is bloated from installing and uninstalling things and shorter times after registry cleaning or defragging.

[Jeremy Collake]

Yea, I will have to work on the output format for sure. In the benchmark, there is currently only one really important metric: "Average time per access". The lower this value, the better.

[Jeremy Collake]

Updated today. Output cleaned up. I will package it in an installer shortly, I suppose.

[XMinioNX]

Hi Jeremy, this tool dragged my computer to a crawl - whether run as Administrator or not.

This is the command I executed: regbench HKLM -auto

Here are my computer specs:

• OS: Windows Vista: Enterprise 64bit
• CPU: Intel Core 2 Quad Q6600 2.6 GHz
• Motherboard: Intel DG33FB
• RAM: 4 GB DDR2 800 MHz
• HDD: 3x Seagate 7200 RPMs (OS - 320 GB; Data - 750 GB and 1.5 TB)

At the time of the benchmark the processes running were:

• Firefox (12 tabs opened)
• Thunderbird
• Win XP Virtual Machine - 768 MB RAM assigned
• Ubuntu VM - 768 MB RAM assigned
• Kaspersky Internet Security
• And regular windows processes

I kept an eye on the Private Working Set of RegBench during the Administrator run and it grew to about 1.76 GB before completely stopping everything on the computer.

[benDan]

Can anyone tell a newbie how to run this?

[Jeremy Collake]

I kept an eye on the Private Working Set of RegBench during the Administrator run and it grew to about 1.76 GB before completely stopping everything on the computer.

Your registry must be quite large . I will work to reduce memory consumption.

[Jeremy Collake]

Can anyone tell a newbie how to run this?

I'm sorry, but it is a console mode application that takes command line switches .. though it does show output in your web browser. If you don't know how to use a console mode application, this utility isn't for you ;(. Maybe at some point I will add a graphical user interface. Until then, you should either learn about console mode applications, or just opt not to use it.

[neal1047]

Interesting idea. I've used Registrar Registry Manager for years. The pro verion will do back-ups and registry defrags. I'll do some testing and give you some feedback. I realize this is not in your mainstream line-up but it might be useful to you sometime.

The Windows registry is a mixed blessing and can cause performance problems (as you obviously know) amongst other evil things. later

[Jeremy Collake]

One of the key reasons I developed RegBench was to see what effect registry defragmentation and cleaning really has on its performance. In theory, it should make a difference, as more optimized registry hives results in quicker traversing through its data structures. However, in practice, it could be that only in extreme situations does the registry hive ever get to a state that severely diminishes system performance. That said, if it isn't the registry, then what does cause the performance degradation we all see with Windows over time? Shell extensions, more programs running, IE add-ons? I dunno, please report any findings you do have.

What we need is a system in 'bad shape', run some RegBench benchmarks and get consistent results, then try cleaning and defragmentation, then re-run the benchmarks in the same system state (or as close as possible, no apps running, etc..).

Also, we must be careful, as the current RegBench consumes a lot of virtual memory, so it may need code modification so that it doesn't end up benchmarking the performance of page swaps (VM pages in and out) instead of the registry ;o. You may try benchmarking the HKCU hive instead of HKLM, to help reduce VM usage in this current version. I will do what I can to reduce memory usage soon.

[britlee]

Oh great, thank you!

[Remah]

One of the key reasons I developed RegBench was to see what effect registry defragmentation and cleaning really has on its performance. In theory, it should make a difference, as more optimized registry hives results in quicker traversing through its data structures. However, in practice, it could be that only in extreme situations does the registry hive ever get to a state that severely diminishes system performance. That said, if it isn't the registry, then what does cause the performance degradation we all see with Windows over time? Shell extensions, more programs running, IE add-ons? I dunno, please report any findings you do have.

What we need is a system in 'bad shape', run some RegBench benchmarks and get consistent results, then try cleaning and defragmentation, then re-run the benchmarks in the same system state (or as close as possible, no apps running, etc..).

Also, we must be careful, as the current RegBench consumes a lot of virtual memory, so it may need code modification so that it doesn't end up benchmarking the performance of page swaps (VM pages in and out) instead of the registry ;o. You may try benchmarking the HKCU hive instead of HKLM, to help reduce VM usage in this current version. I will do what I can to reduce memory usage soon.

Have you given up on developing RegBench further?
Do you know of anyone else who's produced RegBench benchmarks like you described? I haven't found anything, only rumours so I had a go myself. Here's some info on that. More detail will follow when I analyze the data.

I've been using RegBench to benchmark various scenarios on an XP PC that had been used for testing many programs. It was in average rather than bad shape. I tested it:

• Unchanged at 152,500 keys
• After using NTREGOPT to compact hive files
• After registry clean + disk clean + disk defragment -> 151,900 keys
• After uninstalling almost every application and Windows features I didn't need -> 127,000 keys

I also ran tests with 128, 256, and 1024 MB physical memory but not every combination.

The test results were usually consistent as I was running the same test several times on each hive. But I was not happy with some differences I couldn't explain. I didn't restore disk images for matching scenarios due to the small differences in the registry hives - maybe I should have?

At the moment, here's a rough cut from the totals. I've yet to look at individual hive results:

• Enumeration times and access times for repeated tests generally decreased after the first test. I'd expect this with paging. Are there other reasons you can think of?
• The data read in repeated access tests could vary by a factor of 6 which was reflected in fluctuations in the rate of keys accessed.  Maybe it would be better to create a profile by recording actual key use. Then produce a sample that can be used for a more representative and consistent test.
• In general, more memory performed best. 128 MB was 25% slower than 256 MB which was much the same as 1024 MB.  But the best result was using 256 MB RAM rather than 1024 MB.
• NTREGOPT appears to get a marginally better result.
• Cleaning the registry and disk then appears to get a marginally worse result.
• Uninstalling to reduce the registry size by 15% of keys made the most difference with about a 25% improvement in access time. That would make sense if a higher proportion of the keys had longer paths and/or had a higher proportion of values. I'm going to use Dureg to check hive data size compared with key quantity.

I am concerned that RegBench might be affecting the results. That's when I checked here and saw your comment above. So I've now run another set of different scenarios on another XP PC but included system memory usage stats to see what happens. I'm now swimming in data.

I'd also like a bit more detail on does RegBench works under the hood:
How does it choose the keys to access: randomly or some other scheme?
Is there any reason why you chose 100,000 accesses?
How would you improve memory use?