|
|
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
|
|
"Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
news:uvsc1hnRJHA.1148[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > 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?
|
|
Twayne wrote:
[Quoted Text] > 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
|
|
Your over infatuation with the Windows registry is disturbing.
--
----
Crosspost, do not multipost http://www.blakjak.demon.co.uk/mul_crss.htm
How to ask a question http://support.microsoft.com/kb/555375
Help Us Help You http://dts-l.net/goodpost.htm
"Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
news:uvsc1hnRJHA.1148[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] >
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
|
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
David B. wrote:
[Quoted Text] > Your over infatuation with the Windows registry is disturbing.
>
|
|
|
[Quoted Text] > 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
>
> David B. wrote:
>
>> Your over infatuation with the Windows registry is disturbing.
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.
|
|
|
[Quoted Text] > "Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
> news:uvsc1hnRJHA.1148[ at ]TK2MSFTNGP05.phx.gbl...
>> 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?
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?
|
|
|
[Quoted Text] > Twayne wrote:
>
>> 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
|
|
|
[Quoted Text] > Twayne wrote:
>
>> 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
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
|
|
Twayne wrote:
[Quoted Text] >>Twayne wrote:
>>
>>
>>>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
>
>
> 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
[Quote]
*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/documentation/windowsnt/4/workstation/reskit/en-us/23_regov.mspx?mfr=true
John
|
|
Twayne wrote:
[Quoted Text] >> "Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
>> news:uvsc1hnRJHA.1148[ at ]TK2MSFTNGP05.phx.gbl...
>>> 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?
>
> 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.
--
JD..
|
|
"Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
news:eSPad0pRJHA.4524[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] >> 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
>>
>> David B. wrote:
>>
>>> Your over infatuation with the Windows registry is disturbing.
>
> 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
|
|
|
[Quoted Text] > Twayne wrote:
>>> "Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
>>> news:uvsc1hnRJHA.1148[ at ]TK2MSFTNGP05.phx.gbl...
>>>> 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?
>>
>> 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.
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
|
|
Twayne wrote:
[Quoted Text] >> Twayne wrote:
>>>> "Twayne" <nobody[ at ]devnull.spamcop.net> wrote in message
>>>> news:uvsc1hnRJHA.1148[ at ]TK2MSFTNGP05.phx.gbl...
>>>>> 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?
>>> 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.
>
> 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
>
>
>
>
>
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.
--
JD..
|
|
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"
--
There are an infinite number of ways to tell the same lie. There is only one
way to tell the truth.
"John John (MVP)" wrote:
[Quoted Text] > 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
>
> David B. wrote:
>
> > Your over infatuation with the Windows registry is disturbing.
> >
>
>
|
|
|