Welcome Guest.   Make a donation to an author on the site October 24, 2014, 03:33:01 PM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Check out and download the GOE 2007 Freeware Challenge productivity tools.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1]   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: RegBench - Registry Benchmarker Utility  (Read 7150 times)
mouser
First Author
Administrator
*****
Posts: 33,587



see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« on: October 10, 2008, 10:24:35 PM »

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.



from http://www.ghacks.net/200...10/10/registry-benchmark/
Logged
city_zen
Supporting Member
**
Posts: 120


see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #1 on: October 11, 2008, 02:10:33 AM »

OK, looks like I'm first here

I'll show you mine if you show me yours  tongue

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.

« Last Edit: October 11, 2008, 02:17:33 AM by city_zen » Logged

I'll have what she's having
ghacks
Honorary Member
**
Posts: 49


View Profile Give some DonationCredits to this forum member
« Reply #2 on: October 11, 2008, 02:22:01 AM »

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.
Logged
nontroppo
Charter Honorary Member
***
Posts: 648


spinning top

View Profile WWW Give some DonationCredits to this forum member
« Reply #3 on: October 11, 2008, 05:55:50 AM »

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!
Logged

f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #4 on: October 11, 2008, 10:16:41 AM »

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 smiley
Logged

- carpe noctem
city_zen
Supporting Member
**
Posts: 120


see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #5 on: October 11, 2008, 12:19:58 PM »

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 ( ohmy , I guess I should start cutting down on software evaluation  cheesy ). 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)
 
Logged

I'll have what she's having
longrun
Charter Member
***
Posts: 152

View Profile Give some DonationCredits to this forum member
« Reply #6 on: November 04, 2008, 09:24:41 PM »

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.
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #7 on: November 05, 2008, 01:39:49 AM »

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.
Logged

- carpe noctem
mikiem
Participant
*
Posts: 93

see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #8 on: November 05, 2008, 06:07:16 PM »

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.
« Last Edit: November 05, 2008, 06:18:42 PM by mikiem » Logged
city_zen
Supporting Member
**
Posts: 120


see users location on a map View Profile Give some DonationCredits to this forum member
« Reply #9 on: November 06, 2008, 08:16:51 AM »

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.
Logged

I'll have what she's having
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #10 on: November 07, 2008, 05:19:57 AM »

[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 smiley
Logged

- carpe noctem
Stoic Joker
Honorary Member
**
Posts: 5,331



View Profile WWW Give some DonationCredits to this forum member
« Reply #11 on: November 09, 2008, 08:50:10 AM »

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.
Quote
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.
Logged
Darwin
Charter Member
***
Posts: 6,979



see users location on a map View Profile Read user's biography. Give some DonationCredits to this forum member
« Reply #12 on: November 09, 2008, 10:45:15 AM »

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  smiley) for three years now and have never noticed a difference, other than greater overall system stability.

edit by jgpaiva: fixed quote tag
« Last Edit: November 09, 2008, 11:01:21 AM by jgpaiva » Logged

"Some people have a way with words, other people,... oh... have not way" - Steve Martin
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #13 on: November 10, 2008, 05:34:32 AM »

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

- carpe noctem
Pages: [1]   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.047s | Server load: 1.28 ]