Some Registry Measurements

[Twayne]

Registry Use:

I decided to take a look at just what kind of things were in the
registry with respect to installed programs. We already know there are
huge number of entries for the operating system, but how about programs?

So I got out my handy-dandy registry lister tool and the first thing I
counted was a non-MS app, WinZip since many people use it these days.




The counts are as follows:

Keys: 56 4 hives

Values: 52 HK CU, LM, _users

Data: 242 4 hives

-------

Total: 350 registry entries for Winzip.




A VB6 application I wrote and compiled: Only had add/remove entries.
Very little impact on the registry. But that's typical of Vb 6 files.
Their true weight is in the overhead that the operating system carries
with it every day of its life so the counts are low. IMO it makes sense
to not add several frameworks etc. when the os already provides almost
everything needed for a new app.




MS Word 2002 on the other hand, has a whopping 2,384 total entries if I
counted accurately, which I cannot guarantee, but it's going to be
pretty close. I shudder to think what some of the other, more powerful
MS apps might have in the registry.




Multiply those numbers for the remaining MS apps and other apps
installed on the machine and you begin to understand why the registry,
even though it's normally only a text file, gets to be so many megabytes
large.


My current total registry size is about 145 MB and takes about 30
seconds to write to the disk. I would then surmise that at least 30+ S
of my boot time is reading the registry since reads/writes are
approximately equal from disk. A defrag of the disk might change that
time, but that's what it is at the moment.




145 MB is a lot of text. It explains why Regedit can take so long to
find a key or value, too. And why a program can get around the registry
a lot faster than opening it in redegit and doing the changes manually,
especially when you consider that a "change" in the registry may involve
the edit/revision of many, many entries.

Regedit does not "go directly" to any specific location in the registry;
it has to read it into a section of RAM and then search it sequentially
for the search item requested, from top to bottom. It could, actually,
search much faster than it does, but in the typical MS fashion, it does
not. Only the operating system uses the Registry; Regedit does not.

The registry is a "sort of" database, but it doesn't have an actual
"index" as most understand "index". It's index is simply a table it
searches and then tables within a table until finally it switches to
sequential mode to find the specific item it's looking for a match on.

The large size of the text file and lack of any kind of crc or hash
control on it is why corruption can happen to it so easily. The registry
is even more exposed to corruption from the operating system glitches,
malware and poorly written apps than some other parts of the system.
Especially when you consider the very large number of times the registry
is written to or read even while a computer is sitting idle.




How much does the registry actually get used in normal operation?

Well, that's fairly easy to approximate using ntregmon. With all the
filters off, this article, a web page, and one instance of windows
Explorer open, but all idling with the exception of my registry monitor,
we get:

SECONDS WHERE

0.90202265 S elapsed: Regmon.exe:7772
CloseKeyKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2...SUCCESS

1.05899976 S elapsed: spoolsv.exe:1604 OpenKey HKCU... SUCCESS

1.05905522 S elapsed: spoolsv.exe:1604
CreateKeyHKCU\Printers\Dev...SUCCESS

1.05939660 S elapsed: spoolsv.exe:1604 CloseKey HKCU ... SUCCESS




At the 1.05899976 S elapsed: point, there were 2,151 registry accesses
recorded.


At the 10 S elapsed: point, it was 6,251 accesses recorded. I stopped it
at 10 seconds since more time would just be more of the same activity.




The registry is a very busy place! Technically I probably should have
filtered ntregmon from the counts but I forgot to. Even so it would
still leave large numbers of accesses, especially when extended to a
minute, or hour, or day. These accesses are more or less the ONLY
"direct" access to any part of the registry, and they are being done by
the operating system. I don't know of any good apps that can access the
registry as the OS does or even similarly; I wish I did; so I've nothing
to recommend there.




You can easily duplicate my test here with the free tool ntregmon,
available from many places on the 'net. The copy I just used comes from
Microsoft's Sysinternals section but it's no different than the old one
from SysInternals before the purchase. So far at least. And it's free,
of course. It CAN be a very useful program for those who take the time
to learn its abilities, else it's just an interesting "thing" and not
much real use.

Twayne

 

[Daave]

My current total registry size is about 145 MB and takes about 30
seconds to write to the disk. I would then surmise that at least 30+ S
of my boot time is reading the registry since reads/writes are
approximately equal from disk. A defrag of the disk might change that
time, but that's what it is at the moment.

You can test your hypothesis:

1. Measure your actual boot time.

2. Image your hard drive.

3. Clean the registry, using your method of choice.

4. Measure your boot time.

What is the *actual* difference?

 

[John John (MVP)]

The large size of the text file and lack of any kind of crc or hash
control on it is why corruption can happen to it so easily. The registry
is even more exposed to corruption from the operating system glitches,
malware and poorly written apps than some other parts of the system.
Especially when you consider the very large number of times the registry
is written to or read even while a computer is sitting idle.

Corruption of the registry does not happen as easily as you might think,
quite to the contrary the ACID properties of registry transactions and
the use of transactional logs makes the registry very robust indeed!
The registry is not *more* exposed to corruption, the above makes it
*less* exposed to corruption than almost any other file on the hard disk.

John

 

[David B.]

Your over infatuation with the Windows registry is disturbing.

 

[John John (MVP)]

It's all to do with his "opinions" about registry cleaners. Instead of
basing his opinions about cleaners on facts he is now trying to find (or
invent) facts to fit his opinions.

John

 

[Twayne]

It's all to do with his "opinions" about registry cleaners. Instead

of basing his opinions about cleaners on facts he is now trying to
find (or invent) facts to fit his opinions.

John

Yeah, you wish, don't you? When will you ever come up with anything
intelligent or meaningful to say? I'm sorry; I forgot, that's probably
beyond your abilities.

It's all "to do" in your case, with MISINFORMATION you like to parrot
and assume is good information with absolutely no basis of your own to
support it and can't think for yourself if you wanted to. You have an
elementary school playground mentality and show it often here. If
you're so certain of your facts, then prove them to be right. You can
not do that because they are not right. In fact, I don't believe I've
ever seen anything from you that even resembled a fact.

 

[Twayne]

You can test your hypothesis:

1. Measure your actual boot time.

2. Image your hard drive.

3. Clean the registry, using your method of choice.

4. Measure your boot time.

What is the *actual* difference?

Well, that wouldn't really prove much since I maintain the registry
regularly anyway. But the registry wasn't the subject of that para
anyway; disk defragmentation was.

My boot time, end of post to beginning of populating the system tray
runs pretty consistantly around 3 1/2 minutes when I do look at it, so
this particular machine isn't much good for a test unit. Clients
machines are the best for that kind of thing but I haven't had any come
in yesterday or today that warrant any registry work, so ... nothng to
use if I were inclinded to make a point with it.

I have in the past has it take a machine from around 5 minutes down to
about 3 though. But the closed minds here don't want to hear it because
they might have to admit to having "seen" data that goes against their
claims about registry cleaner applications.

Why don't you do the same tests?

 

[Twayne]

Corruption of the registry does not happen as easily as you might
think, quite to the contrary the ACID properties of registry
transactions and the use of transactional logs makes the registry
very robust indeed! The registry is not *more* exposed to corruption,
the above makes it
*less* exposed to corruption than almost any other file on the hard
disk.
John

 

[Twayne]

Corruption of the registry does not happen as easily as you might
think, quite to the contrary the ACID properties of registry
transactions and the use of transactional logs makes the registry
very robust indeed! The registry is not *more* exposed to corruption,
the above makes it
*less* exposed to corruption than almost any other file on the hard
disk.
John

ACID "properties"? I assume you're referring to trasnactional
management, callbacks, pre/post and such. There is something to that,
surely, and I can't argue against that.
I do have to admit , that in the overall, it is NOT "more exposed ...
" as I said. That was a bad statement. The registry in XP is actually
pretty robust. It's also impractical in its present format/methodology
for the registry to ever be subject to hashing of any type without
serious performance hits, I'm sure.
Corruption still happens though, and too often IMO. The very nature
of the registry almost invites corruption via the very high activity
it's constantly submitted to.

Thanks for the catch,

Twayne

 

[John John (MVP)]

ACID "properties"? I assume you're referring to trasnactional
management, callbacks, pre/post and such. There is something to that,
surely, and I can't argue against that.
I do have to admit , that in the overall, it is NOT "more exposed ...
" as I said. That was a bad statement. The registry in XP is actually
pretty robust. It's also impractical in its present format/methodology
for the registry to ever be subject to hashing of any type without
serious performance hits, I'm sure.
Corruption still happens though, and too often IMO. The very nature
of the registry almost invites corruption via the very high activity
it's constantly submitted to.

Registry corruption is not as prevalent as you make it out to be. Many,
if not must users will never experience registry corruption. Users may
suffer problems caused by improper, missing or deleted entries in the
registry but these problems are rarely caused by corruption, these
problems are usually caused by deliberate user actions, by the user's
applications, by registry cleaners or by malware. Very rarely are those
problems caused by corruption, users should not confuse registry damage
cause by their willful actions or that of their applications with
registry corruption.

Some users may be so unfortunate as to get the infamous "Windows could
not start because the following file is missing or corrupt:
\WINDOWS\SYSTEM32\CONFIG\..." error message when they boot their
computer but even that is not something that most users will ever have
to deal with. Also, although the error may be caused by registry
corruption, quite often the corruption problem is actually caused by
disk corruption which in turn leads to corruption or missing registry
files, the corruption is not usually caused by registry activity while
Windows is running.

ACID: Atomicity, Consistency, Isolation, and Durability

*Atomicity and Hive Recovery in the Registry*

The Registry ensures atomicity of individual actions. This means that
any change made to a value (to set, delete, or save) either works or
does not work: The result will not be a corrupted combination of the old
and new configuration even if the system stops unexpectedly because of
power failure, hardware failure, or software problems. For example, if
an application sets a value for an entry and the system shuts down while
this change is being made, when the system restarts, the entry will have
either the old value or the new value, but not a meaningless combination
of both values. In addition, the size and time data for the key
containing the affected entry will be accurate whether the value was
changed or not changed.

*Flushing Data*

In Windows NT, data is written to the Registry only when a flush occurs,
which happens after changed data ages past a few seconds, or when an
application intentionally flushes the data to the hard disk.

The system performs the following flush process for all hives (except
for the System hive):

1. All changed data is written to the hive's .log file along with a map
of where it is in the hive, and then a flush is performed on the .log
file. All changed data has now been written in the .log file.

2. The first sector of the hive file is marked to indicate that the file
is in transition.

3. The changed data is written to the hive file.

4. The hive file is marked as completed.

Note If the system shuts down between steps 2 and 4, when the hive is
next loaded at startup (unless it's a profile hive that is loaded at
logon), the system sees the mark left in step 2, and proceeds to recover
the hive using the changes contained in the .log file. That is, the .log
files are not used if the hive is not in transition. If the hive is in
transition, it cannot be loaded without the .log file.

A different flush process is used for the System hive because it is an
important element during system startup and is used too early during
startup to be recovered as described in the previous flush process.

The System.alt file contains a copy of the data contained in the System
file. During the flush process, changes are marked, written, and then
marked as done. Then the same flush process is followed for the
System.alt file. If there is a power failure, hardware failure, or
software problems at any point during the process, either the System or
System.alt file contains the correct information.

The System.alt file is similar to a .log file except that at load time,
rather than having to reapply the logged changes, the system just
switches to System.alt. The System.alt file is not needed unless the
System hive is in transition.

[end quote]

http://www.microsoft.com/resources/...rkstation/reskit/en-us/23_regov.mspx?mfr=true

John

 

[JD]

Well, that wouldn't really prove much since I maintain the registry
regularly anyway. But the registry wasn't the subject of that para
anyway; disk defragmentation was.

My boot time, end of post to beginning of populating the system tray
runs pretty consistantly around 3 1/2 minutes when I do look at it, so
this particular machine isn't much good for a test unit. Clients
machines are the best for that kind of thing but I haven't had any come
in yesterday or today that warrant any registry work, so ... nothng to
use if I were inclinded to make a point with it.

I have in the past has it take a machine from around 5 minutes down to
about 3 though. But the closed minds here don't want to hear it because
they might have to admit to having "seen" data that goes against their
claims about registry cleaner applications.

Why don't you do the same tests?

3.5 minutes from post to the *beginning* of populating the system tray?
I'm using XPhe with all the updates and my system tray is populated in
less than a minute after post. I'll time it tomorrow morning when I
start the computer.

I'm using a AMD Athlon 64 X2 dual core processor 6000+ with 4 GB of RAM.

My system tray is populated with the following icons: ATI Catalyst
Control Center, Zone Alarm, Volume, Realtek HD Audio Manager, Smart
Office Keyboard and the clock. More icons than I'm used to but I'm still
tuning the build.

The system is about two months old, built by me.

I've never used a Registry cleaner but I have mucked around in the
registry when necessary, which is very infrequently. Let sleeping dogs lie.

 

[Mike Hall - MVP]

Yeah, you wish, don't you? When will you ever come up with anything
intelligent or meaningful to say? I'm sorry; I forgot, that's probably
beyond your abilities.

It's all "to do" in your case, with MISINFORMATION you like to parrot and
assume is good information with absolutely no basis of your own to support
it and can't think for yourself if you wanted to. You have an elementary
school playground mentality and show it often here. If you're so certain
of your facts, then prove them to be right. You can not do that because
they are not right. In fact, I don't believe I've ever seen anything from
you that even resembled a fact.

You have still failed to produce anything meaningful which shows that use of
a Registry cleaner speeds anything up..

--
Mike Hall - MVP
How to construct a good post..
http://dts-l.com/goodpost.htm
How to use the Microsoft Product Support Newsgroups..
http://support.microsoft.com/default.aspx?pr=newswhelp&style=toc
Mike's Window - My Blog..
http://msmvps.com/blogs/mikehall/default.aspx

 

[Twayne]

3.5 minutes from post to the *beginning* of populating the system
tray? I'm using XPhe with all the updates and my system tray is
populated in less than a minute after post. I'll time it tomorrow
morning when I start the computer.

I'm using a AMD Athlon 64 X2 dual core processor 6000+ with 4 GB of
RAM.

Mmm, nice system! I'll bet you can do some really serious work with
that.

My system tray is populated with the following icons: ATI Catalyst
Control Center, Zone Alarm, Volume, Realtek HD Audio Manager, Smart
Office Keyboard and the clock. More icons than I'm used to but I'm
still tuning the build.

Actually I have quite a few items in my system tray but I would expect
yours to populate pretty fast even if you had my load! It'll be
interesting to see your numbers. Depending on which profile I'm using I
have as many as 15 items in the system tray or as few as three (clock,
ZA, UPS and NVidia settings). My video profile is somewhere in the
middle and my "everyday use" has the 15; I have 4 total profiles
depending on what I'm going to do. The numbers are from the 15 items
and contain things such as ZA, clock, NVidia, VBScroll, WinPatrol, a
weather station, UPS status, AV, Ghost, a reminder app to tell me to
take meds when it's time, CD/DVD, Printer, Volume, Remove Hardware. I
probably missed a few. The weather station, ZA, AV and Ghost take the
most time to get going.
I see a lot of machines come in where the systray population makes
almost no difference in getting the machine to the point of being
completely ready to use to those like mine, where the processes take
enough cpu to make the machine pause a bit until they're finished up. I
could unload a lot of them but they're easier to get at their and once
the boot is done, I don't really notice they're there.
Got a Gig of RAM and run a Pagefile & a cpu monitor right now since i
recently moved the pf to a different disk and what to be able to see it
at anytime. Thought I might need to go one more Gig but guess not; pf
use looks fine; never changes in normal use.

The system is about two months old, built by me.

I've never used a Registry cleaner but I have mucked around in the
registry when necessary, which is very infrequently. Let sleeping
dogs lie.

Well, that's not a bad thing. Overall, the registry isn't normally the
source of problems anyway. It sounds like you have the wherewithal to
keep things in line . It's always best to do things the way one is
comfortable with anyway; saves a lot of confusion sometimes and can
minimize a lot of problems.

Cheers,

Twayne

 

[JD]

Mmm, nice system! I'll bet you can do some really serious work with
that.


Actually I have quite a few items in my system tray but I would expect
yours to populate pretty fast even if you had my load! It'll be
interesting to see your numbers. Depending on which profile I'm using I
have as many as 15 items in the system tray or as few as three (clock,
ZA, UPS and NVidia settings). My video profile is somewhere in the
middle and my "everyday use" has the 15; I have 4 total profiles
depending on what I'm going to do. The numbers are from the 15 items
and contain things such as ZA, clock, NVidia, VBScroll, WinPatrol, a
weather station, UPS status, AV, Ghost, a reminder app to tell me to
take meds when it's time, CD/DVD, Printer, Volume, Remove Hardware. I
probably missed a few. The weather station, ZA, AV and Ghost take the
most time to get going.
I see a lot of machines come in where the systray population makes
almost no difference in getting the machine to the point of being
completely ready to use to those like mine, where the processes take
enough cpu to make the machine pause a bit until they're finished up. I
could unload a lot of them but they're easier to get at their and once
the boot is done, I don't really notice they're there.
Got a Gig of RAM and run a Pagefile & a cpu monitor right now since i
recently moved the pf to a different disk and what to be able to see it
at anytime. Thought I might need to go one more Gig but guess not; pf
use looks fine; never changes in normal use.


Well, that's not a bad thing. Overall, the registry isn't normally the
source of problems anyway. It sounds like you have the wherewithal to
keep things in line . It's always best to do things the way one is
comfortable with anyway; saves a lot of confusion sometimes and can
minimize a lot of problems.

Cheers,

Twayne

The numbers:

9 sec to post

23 seconds to the first windows screen

43 seconds to the first icon to populate the system tray

54 seconds to full windows, all icons in the system tray

I forgot to mention there is also a Anti-Virus icon in the system tray.

 

[John M]

I wonder what else they like to measure?

Actually, I learned a few things about registrys just reading all this stuff
and I'm a computer retard. I even changed mine as per your directions.
John M
from "Can't creat a New shortcut"