PDA

View Full Version : registry cleaning and size


Bill Cunningham[_2_]
July 25th 15, 08:05 PM
I have heard that the registry as far as fragmentation and compression
takes care of its' self. What's that mean? I understand the pagefile not
fragmenting but the registry files are changing size are they? With the
insertion and deletion of hive keys.

Bill

VanguardLH[_2_]
July 25th 15, 09:40 PM
Bill Cunningham wrote:

> I have heard that the registry as far as fragmentation and compression
> takes care of its' self. What's that mean? I understand the pagefile
> not fragmenting but the registry files are changing size are they?
> With the insertion and deletion of hive keys.

Fragmentation of the registry files is meaningless. The files
themselves are not read to get registry entries. When Windows starts,
the registry is copied into memory. All apps get their registry values
from the copy in memory. System memory is random read meaning it is the
same time to access no matter where the data is stored in the memory.
Defragging the registry files (which has to be performed during Windows
startup so you need a defragger that can run at boot-time) will not
shorten load time for Windows.

Reducing the size of the registry files by deleting orphaned entries
will speed the time to load the registry files into memory. However,
the reduction in files size may account for all of 2 ms in speed up in
load time which you will never notice. The primary goal is to reduce
how much system RAM is used for the memory copy of the registry. In
really bad scenarios, I've seen a reduction of 25 MB; however, if that
amount of memory is the difference between your computer having enough
reserved (free) memory or not to let you load more processes then you
are already too low on system RAM and need to focus on upping that.

There is no compression of the registry files. They are binary
databases, not text databases. What you see in regedit.exe is NOT how
the data is stored in the registry files. regedit.exe uses the Registry
API to display [some of] the registry. Compression would increase the
time to extract the files to copy them into memory on boot.

The registry files do not change in size as you imply. They always
increase in size. A few bytes you might clean out of the registry is
puny compared to the install of a new program or of entries added by
Windows itself during its operation. Registry cleanup will reduce the
size but also incur a hazard that entries are deleted that should not
be. Registry cleaners have a limited experience by their coders and a
limited knowledge in the coding of the cleaner tool. Some cleaners are
too aggressive and result in deleting entries that are really need.
Most do not trace through dependencies for entries on other entries or
chaining of entries. Registry cleaners should only be used by expert
registry editing users who know what the entries are for or are willing
to do the research to make sure the proposed changes are valid.
Cleaners are a convenience tool used by experts, not to be used by boobs
that haven't a clue or won't research what an entry is for. If the
registry cleaner doesn't list every proposed change then don't use it.
Using a cleaner blind is guaranteed to cause problems, like Windows will
cease to load. After it presents a list of proposed changes, the *user*
is still responsible for the administration of their own computer (since
they relegated that task to themself instead of paying for support) so
they are responsible for knowing and authorizing the proposed changes.
While some registry cleaners offer a backup of the proposed changes, how
are you going to restore from that backup if Windows won't boot? You
need Windows to load and still need the registry cleaner to load so it
can read its backup file. A registry cleaner is like a car engine
analyzer: unless you know how to use the tool, its use by a boob is
futile or even possible dangerous. A registry cleaner should be
considered a convenience tool used only by those that are adept in
editing the registry - or willing to take the risk the tool is smarter
than the user (not always true).

Bill Cunningham[_2_]
July 26th 15, 12:10 AM
"VanguardLH" > wrote in message
...

> Fragmentation of the registry files is meaningless. The files
> themselves are not read to get registry entries. When Windows starts,
> the registry is copied into memory. All apps get their registry values
> from the copy in memory. System memory is random read meaning it is the
> same time to access no matter where the data is stored in the memory.
> Defragging the registry files (which has to be performed during Windows
> startup so you need a defragger that can run at boot-time) will not
> shorten load time for Windows.
>
> Reducing the size of the registry files by deleting orphaned entries
> will speed the time to load the registry files into memory. However,
> the reduction in files size may account for all of 2 ms in speed up in
> load time which you will never notice. The primary goal is to reduce
> how much system RAM is used for the memory copy of the registry. In
> really bad scenarios, I've seen a reduction of 25 MB; however, if that
> amount of memory is the difference between your computer having enough
> reserved (free) memory or not to let you load more processes then you
> are already too low on system RAM and need to focus on upping that.

How do you know about 25 MB of RAM? Do you know the addresses virtual or
physical that contain the registry files? The RAM addresses? I am curious.

> There is no compression of the registry files. They are binary
> databases, not text databases. The files What you see in regedit.exe is
> NOT how
> the data is stored in the registry files. regedit.exe uses the Registry
> API to display [some of] the registry. Compression would increase the
> time to extract the files to copy them into memory on boot.
>
> The registry files do not change in size as you imply. They always
> increase in size. A few bytes you might clean out of the registry is
> puny compared to the install of a new program or of entries added by
> Windows itself during its operation. Registry cleanup will reduce the
> size but also incur a hazard that entries are deleted that should not
> be. Registry cleaners have a limited experience by their coders and a
> limited knowledge in the coding of the cleaner tool. Some cleaners are
> too aggressive and result in deleting entries that are really need.
> Most do not trace through dependencies for entries on other entries or
> chaining of entries. Registry cleaners should only be used by expert
> registry editing users who know what the entries are for or are willing
> to do the research to make sure the proposed changes are valid.
> Cleaners are a convenience tool used by experts, not to be used by boobs
> that haven't a clue or won't research what an entry is for. If the
> registry cleaner doesn't list every proposed change then don't use it.
> Using a cleaner blind is guaranteed to cause problems, like Windows will
> cease to load. After it presents a list of proposed changes, the *user*
> is still responsible for the administration of their own computer (since
> they relegated that task to themself instead of paying for support) so
> they are responsible for knowing and authorizing the proposed changes.
> While some registry cleaners offer a backup of the proposed changes, how
> are you going to restore from that backup if Windows won't boot? You
> need Windows to load and still need the registry cleaner to load so it
> can read its backup file. A registry cleaner is like a car engine
> analyzer: unless you know how to use the tool, its use by a boob is
> futile or even possible dangerous. A registry cleaner should be
> considered a convenience tool used only by those that are adept in
> editing the registry - or willing to take the risk the tool is smarter
> than the user (not always true).

OK. Thanks much for the info. I noticed compression never amounted to
much. Unlike a JPEG of JFIF raw image that is compressed. :)

Bill

VanguardLH[_2_]
July 26th 15, 02:32 AM
Bill Cunningham wrote:

> How do you know about 25 MB of RAM? Do you know the addresses virtual or
> physical that contain the registry files? The RAM addresses? I am curious.

Registry file under %windir%\System32\config (hidden folder)
COMPONENTS
DEFAULT
SECURITY
SOFTWARE
SYSTEM
(also has SAM database here)
User registry at
%USERPROFILE%\NTUSER.DAT
%USERPROFILE%\AppData\Local\Microsoft\Windows\UsrC lass.dat

Total up their byte size (file size, not size on disk). Do a cleanup on
the registry. Recalc the file sizes. This is not accurate but close.

Microsoft had a dureg.exe tool to estimate registry size. Last I
remember it was part of the Windows 2000 Resource Kit that you could get
for free from Microsoft's FTP site (ftp.microsoft.com but that looks to
be gone now). Looks to be available at Softpedia as a download there
(http://www.softpedia.com/dyn-search.php?search_term=dureg). Tried to
run it but it immediately crashes so it may not be usable on 64-bit
versions of Windows (which is what I have, no 32-bit versions anymore).

I suppose you could use ERUNT to backup the registry, check the size of
its backup files, do the registry cleanup (not defrag since that won't
be reducing the size of the databases within the files), and then do
another ERUNT to see what size are the new backup files. ERUNT has not
been updated for awhile (since 2005) but a changelog note says it was
fixed to support x64 Windows. Read their FAQ on problems running ERUNT
while UAC is enabled.

Another crude way would be to use regedit.exe to export the registry.
However, regedit does not have access to the Security and some other
keys (even admins aren't allowed to use regedit to modify those values).
Of course, you or the registry cleanup tool won't be affecting those
hidden registry areas, either.

As I recall, back in Windows XP in one of the config UIs (perhaps
System) showed an estimate of the registry size. That disappeared in
Vista.

Bill Cunningham[_2_]
July 26th 15, 05:43 PM
"VanguardLH" > wrote in message
...
> Bill Cunningham wrote:
>
>> How do you know about 25 MB of RAM? Do you know the addresses virtual or
>> physical that contain the registry files? The RAM addresses? I am
>> curious.
>
> Registry file under %windir%\System32\config (hidden folder)
> COMPONENTS
> DEFAULT
> SECURITY
> SOFTWARE
> SYSTEM
> (also has SAM database here)
> User registry at
> %USERPROFILE%\NTUSER.DAT
> %USERPROFILE%\AppData\Local\Microsoft\Windows\UsrC lass.dat
>
> Total up their byte size (file size, not size on disk). Do a cleanup on
> the registry. Recalc the file sizes. This is not accurate but close.
>
> Microsoft had a dureg.exe tool to estimate registry size. Last I
> remember it was part of the Windows 2000 Resource Kit that you could get
> for free from Microsoft's FTP site (ftp.microsoft.com but that looks to
> be gone now). Looks to be available at Softpedia as a download there
> (http://www.softpedia.com/dyn-search.php?search_term=dureg). Tried to
> run it but it immediately crashes so it may not be usable on 64-bit
> versions of Windows (which is what I have, no 32-bit versions anymore).
>
> I suppose you could use ERUNT to backup the registry, check the size of
> its backup files, do the registry cleanup (not defrag since that won't
> be reducing the size of the databases within the files), and then do
> another ERUNT to see what size are the new backup files. ERUNT has not
> been updated for awhile (since 2005) but a changelog note says it was
> fixed to support x64 Windows. Read their FAQ on problems running ERUNT
> while UAC is enabled.
>
> Another crude way would be to use regedit.exe to export the registry.
> However, regedit does not have access to the Security and some other
> keys (even admins aren't allowed to use regedit to modify those values).
> Of course, you or the registry cleanup tool won't be affecting those
> hidden registry areas, either.
>
> As I recall, back in Windows XP in one of the config UIs (perhaps
> System) showed an estimate of the registry size. That disappeared in
> Vista.

You know I remember in win98 there were two registry files. user.dat and
system.dat. There was no system file protection so the registry key with the
registry header was saved. The dat files could be erased and new registry
files created from the exported file. This MS said had the effect of
"compressing" the registry. The recreated files did have a different size.

Bill

VanguardLH[_2_]
July 26th 15, 10:48 PM
Bill Cunningham wrote:

> "VanguardLH" > wrote in message
> ...
>> Bill Cunningham wrote:
>>
>>> How do you know about 25 MB of RAM? Do you know the addresses virtual or
>>> physical that contain the registry files? The RAM addresses? I am
>>> curious.
>>
>> Registry file under %windir%\System32\config (hidden folder)
>> COMPONENTS
>> DEFAULT
>> SECURITY
>> SOFTWARE
>> SYSTEM
>> (also has SAM database here)
>> User registry at
>> %USERPROFILE%\NTUSER.DAT
>> %USERPROFILE%\AppData\Local\Microsoft\Windows\UsrC lass.dat
>>
>> Total up their byte size (file size, not size on disk). Do a cleanup on
>> the registry. Recalc the file sizes. This is not accurate but close.
>>
>> Microsoft had a dureg.exe tool to estimate registry size. Last I
>> remember it was part of the Windows 2000 Resource Kit that you could get
>> for free from Microsoft's FTP site (ftp.microsoft.com but that looks to
>> be gone now). Looks to be available at Softpedia as a download there
>> (http://www.softpedia.com/dyn-search.php?search_term=dureg). Tried to
>> run it but it immediately crashes so it may not be usable on 64-bit
>> versions of Windows (which is what I have, no 32-bit versions anymore).
>>
>> I suppose you could use ERUNT to backup the registry, check the size of
>> its backup files, do the registry cleanup (not defrag since that won't
>> be reducing the size of the databases within the files), and then do
>> another ERUNT to see what size are the new backup files. ERUNT has not
>> been updated for awhile (since 2005) but a changelog note says it was
>> fixed to support x64 Windows. Read their FAQ on problems running ERUNT
>> while UAC is enabled.
>>
>> Another crude way would be to use regedit.exe to export the registry.
>> However, regedit does not have access to the Security and some other
>> keys (even admins aren't allowed to use regedit to modify those values).
>> Of course, you or the registry cleanup tool won't be affecting those
>> hidden registry areas, either.
>>
>> As I recall, back in Windows XP in one of the config UIs (perhaps
>> System) showed an estimate of the registry size. That disappeared in
>> Vista.
>
> You know I remember in win98 there were two registry files. user.dat and
> system.dat. There was no system file protection so the registry key with the
> registry header was saved. The dat files could be erased and new registry
> files created from the exported file. This MS said had the effect of
> "compressing" the registry. The recreated files did have a different size.
>
> Bill

Awhile back, cars didn't have air bags, automatics, seat belts, or
safety glass. Things change.

Google