Main Area and Open Discussion > General Software Discussion

RegBench - Registry Benchmarker Utility

<< < (3/3)

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.]-mikiem (November 05, 2008, 06:07 PM)
--- End quote ---
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.-mikiem (November 05, 2008, 06:07 PM)
--- End quote ---
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.
-mikiem (November 05, 2008, 06:07 PM)
--- End quote ---
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.-city_zen (November 06, 2008, 08:16 AM)
--- End quote ---
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.-f0dder (November 05, 2008, 01:39 AM)
--- End quote ---
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.

--- End quote ---
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.-f0dder (November 05, 2008, 01:39 AM)
--- End quote ---
Me too, as all to often they end up breaking something that is impossible to spot until it's to late.
-Stoic Joker (November 09, 2008, 08:50 AM)
--- End quote ---

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?

Navigation

[0] Message Index

[*] Previous page