RegBench - Registry Benchmarker Utility

[mouser]

Looks like DC friend Jeremy Collake (maker of PECompact) released a cool little utility recently that benchmarks registry speed.

As Martin on ghacks points out, this will finally make it much easier to answer the questions about the effects of registry defragging and cleaning.  I can't wait to see the benchmark scores on before and after registry defragging so we can see what the real speedup is.

http://www.bitsum.com/regbench.php

from http://www.ghacks.net/2008/10/10/registry-benchmark/

[city_zen]

OK, looks like I'm first here

I'll show you mine if you show me yours 

Here are my results before and after using jkdefrag's Registry Optimization and the difference in % :

HKEY_LOCAL_MACHINE

Average random access time per entry 0.012500 ms 0.012810 ms 2%
Average random read time per byte    0.000200 ms 0.000210 ms 5%

HKEY_CURRENT_USER

Average random access time per entry 0.009380 ms 0.009370 ms 0%
Average random read time per byte    0.000040 ms 0.000020 ms -50%

HKEY_CLASSES_ROOT

Average random access time per entry 0.027350 ms 0.027180 ms -1%
Average random read time per byte    0.000470 ms 0.000470 ms 0%

HKEY_CURRENT_CONFIG

Average random access time per entry 0.006090 ms 0.006250 ms 3%
Average random read time per byte    0.000000 ms 0.000000 ms 0%

HKEY_USERS

Average random access time per entry 0.010000 ms 0.010160 ms 2%
Average random read time per byte    0.000030 ms 0.000040 ms 33%


AVERAGE OF ALL HIVES

Average random access time per entry 0.013064 0.013154 0.7%
Average random read time per byte    0.000185 0.000185 0%


It actually made it worse, if only by 0.7 %

But let me mention that I had run jkdefrag a couple of days ago, so that may explain the minuscule difference

I also tried to run Tuneup Utilities' Registry Defrag afterwards, but it told me that "my registry didn't need defragging"

In any case, it looks like you can at most improve your registry access speed by a millisecond ... hardly worth it


Thank you for the link, Mouser. It surely is an "enlightening" little utility.

[ghacks]

Well it is not all about access speed. The Registry is loaded during system start and a smaller Registry is loading faster thus reducing system load time.

[nontroppo]

Yes, but if again it loads only 1ms quicker at start, that is probably swallowed up by the variability elsewhere. Anyone times windows start times before/after?

Still very interesting stuff!

[f0dder]

Afaik windows doesn't load the entire registry (nor even the entire hive files), but does on-demand loading. I could be wrong, though. But even with full hivefile loading, you would need some serious compacting before you'd be able to see much improvement - it'd take a pretty old harddrive to go below 40MB/s sustained read, probably even on laptops (mine does 65MB/s -> 30MB/s, averaging at ~50MB/s. But that is a 7200rpm drive (rpm should have more to do with seek time than transfer speed, though)).

I would expect that keeping the hive files defragmented is more important than keeping them compacted - having to seek back and forth kills read performance rather quickly.

Anyway, even if the hive files have on-demand access rather than full loading, at the point you're at your desktop and ready to run the benchmark, big parts are pretty much guaranteed to be already loaded and cached. I guess that to actually say anything about performance, you'd need to boot from a different windows install and load "cold" hivefiles instead. Just a thought

[city_zen]

Well it is not all about access speed. The Registry is loaded during system start and a smaller Registry is loading faster thus reducing system load time.

In theory, yes; in practice, not so much ...
I've just made a full backup of my registry and it shows a total size of 98 MB ( , I guess I should start cutting down on software evaluation  ). Let's say that an effective cleaner/defragger can reduce that size by 10% (unlikely). That'd be a 10 MB reduction. If an average HDD can provide 40 MB/s read speed, that translates as a 0.25 second reduction in system startup time. It could be a little more considering fewer seeks due to the defragging, but I guess that the maximum improvement could be in the order of half a second in system startup time.

Anyone times windows start times before/after?

No, I didn't time Windows start time before and after, but I'd be surprised if it made a measurable difference.
By the way, let me mention a little known tip that improves system startup times: the undocumented "-b" switch of defrag.exe . Supposedly Windows does the same thing every three days during system idle times, but you can force it to defrag boot files by running "defrag.exe c: -b"
This is basically the same thing that BootVis does (minus the driver delay analysis, of course)

[longrun]

I used to use registry repair and compaction utilities but concluded that they caused more problems than they solved. Now I concentrate on not mucking up the registry by using Altiris SVS.

[f0dder]

Registry compaction (as in, simply re-creating the hive files) shouldn't cause problems, but registry "repair" or "cleanup"? I've stayed clear from that kind of stuff for quite some time.

Btw, I wonder if registry compaction might actually be counter-productive? If you keep the extra "fluff" around (but keep the hive files defragmented), the "fluff" can be re-used without causing the hive file to grow (and thus possibly causing file fragmentation). On the other hand, re-using the "fluff" can cause internal fragmentation. Ho humm.

[mikiem]

I *think* at least portions of the registry are loaded with windows -- otherwise certain changes wouldn't require a re-boot to take effect.

[a case in point if someone's curious, ATI's CCC applet. Editing the reg entries for CCC is routine for me after a driver update in XP Pro 32 SP3, in order to get some of the Avivo controls visible... It's then nec. to restart for changes to occur -- stopping everything to do with CCC & restarting just those apps & services has no effect. Therefore I'd assume that at least portions of the registry were loaded once, on startup.]

That said, if you start up Sys Internals' reg monitoring program you'll see hundreds of constant entries - I wonder whether defragging the registry files themselves could make a major difference with all that going on? Granted not all keys are routinely accessed, but those that are it stands to reason would be the ones that would benefit the most. Kind of a catch 22 IMHO.

RE: ERUNT & NTREGOPT, the latter just rewrites the registry in one go, start to finish in separate files. Assuming it writes these files to free space without fragmentation, the individual files themselves should be faster to read than if they were spread out over your drive surface. The only time or place I've seen it make a real difference, is when there were bad entries in the registry files that re-writing took care of - either by writing them correctly or skipping them altogether, but then I like to boot into Vista to use JKDefrag on my XP drive, so unless I've been lazy they're not too badly fragmented anyways.

AFAIK reg cleaners, optimizers and such can only look for orphans -- references to other keys or files that don't exist. It can't tell you that a .DLL added by a program install, is still on your drive & referenced in the reg, long after the program's been uninstalled. And, I can tell you from experience that some software inserts so-called orphans on installation, & requires those entries to work properly.

I've taken to saving a regshot compare log with any program I'm just trying, along with doing a backup with ERUNT beforehand. In many cases I'm able to save just one or two critical keys, revert the reg to backup, then add just those keys to eliminate hundreds & sometimes thousands of useless registry alterations from the installation program. In fact, I'll often save a zipped file of the installed app with those reg keys, saving a LOT of hassle should I like the software & add it to a 2nd or 3rd PC. I've got loads of stuff installed in XP, & right now the latest ERUNT backup comes in at 47 MB. Vista OTOH with pretty much the same software comes in at just short of 90.

[city_zen]

Has anyone else benchmarked their Registry before and after a Registry optimization/defragging? I'm curious to see if I'm the only one who saw almost no difference in access/read time.
Please post your results if you've done so.

[f0dder]

[a case in point if someone's curious, ATI's CCC applet. Editing the reg entries for CCC is routine for me after a driver update in XP Pro 32 SP3, in order to get some of the Avivo controls visible... It's then nec. to restart for changes to occur -- stopping everything to do with CCC & restarting just those apps & services has no effect. Therefore I'd assume that at least portions of the registry were loaded once, on startup.]

It's likely that those settings are driver-related, then - that requires a reboot, since most hardware drivers can't just be restarted once windows is running.

That said, if you start up Sys Internals' reg monitoring program you'll see hundreds of constant entries - I wonder whether defragging the registry files themselves could make a major difference with all that going on? Granted not all keys are routinely accessed, but those that are it stands to reason would be the ones that would benefit the most. Kind of a catch 22 IMHO.

Those are mostly reads, and will be cached in memory - thus, no disk access, and no major performance boost.

I've taken to saving a regshot compare log with any program I'm just trying, along with doing a backup with ERUNT beforehand. In many cases I'm able to save just one or two critical keys, revert the reg to backup, then add just those keys to eliminate hundreds & sometimes thousands of useless registry alterations from the installation program. In fact, I'll often save a zipped file of the installed app with those reg keys, saving a LOT of hassle should I like the software & add it to a 2nd or 3rd PC. I've got loads of stuff installed in XP, & right now the latest ERUNT backup comes in at 47 MB. Vista OTOH with pretty much the same software comes in at just short of 90.

I wonder why bother doing this? The disk space saved is neglicible, and considering that the registry uses binary search to lookup keys, you're not going to save a lot of processing time either.

Has anyone else benchmarked their Registry before and after a Registry optimization/defragging? I'm curious to see if I'm the only one who saw almost no difference in access/read time.
Please post your results if you've done so.

Can't be bothered posting results, since differences was within the low-miliseconds range... in other words, not measurable. As I already wrote you'd need "offline" benchmarks of "cold" hivefiles in order to do any kind of quantifiable measurement... but that'd of course be a somewhat irrelevant benchmark, since it doesn't show how a real live system performs.

I guess the conclusion is that the registry is pretty well implemented and cached already

[Stoic Joker]

Registry compaction (as in, simply re-creating the hive files) shouldn't cause problems, but registry "repair" or "cleanup"? I've stayed clear from that kind of stuff for quite some time.

Me too, as all to often they end up breaking something that is impossible to spot until it's to late.

Btw, I wonder if registry compaction might actually be counter-productive? If you keep the extra "fluff" around (but keep the hive files defragmented), the "fluff" can be re-used without causing the hive file to grow (and thus possibly causing file fragmentation). On the other hand, re-using the "fluff" can cause internal fragmentation. Ho humm.

Anything within reason (/moderation).
Compacting it after a few month of extensive software testing = Good Idea
Compacting it every weekend, Just to be thorough... is foolish

I think the main scale tipper is the one two punch of both internal fragmentation/head space/slack/"fluff" coupled with external file level fragmentation. Granted a truely robust database should be able to handle a some abuse...but... Once that combination goes past a certain point lunching the db is only a matter of time.

This is (part of) why large high speed/traffic/demand databases like Exchange must be segregated to their own partition, to prevent catastrophic interaction with other files that need to be allocated around as the elbbubmug grows.

Sure the registry is a much tinyer ... but the same (albeit scaled-down) rules still apply.

[Darwin]

Registry compaction (as in, simply re-creating the hive files) shouldn't cause problems, but registry "repair" or "cleanup"? I've stayed clear from that kind of stuff for quite some time.

Me too, as all to often they end up breaking something that is impossible to spot until it's to late.

Me three... my "history" with registry cleaning is exactly as f0dder describes. This is a contentious issue, though, as there are a lot of people, even tech writers and analysts, that swear by, and recommend registry cleaning as part of computer maintenance. I've been reg cleaner free (clean, so to speak  ) for three years now and have never noticed a difference, other than greater overall system stability.

edit by jgpaiva: fixed quote tag

[f0dder]

Darwin: probably the same people who recommend SpinRite... might have a financial interest in it?