Post by Stan BrownPost by Bob_SBut consider that on system with limited storage - say 32GB of eMMC, saving
a MB or two by cleaning the registry out can make a difference in performing
an update or maybe adding some software you want.
I can't imagine how that can be true.
For one thing, there's virtual memory. For another, a 1 MB increment
in real memory of 32 GB is 0.003%.
Maybe he meant that there was a maximum aggregate file size for all the
.dat files that comprise the registry, like the total or maximum size of
the registry had some upper bound.
https://technet.microsoft.com/en-us/library/cc963194.aspx
In my Windows 7, RegistrySizeLimit = undefined and PagedPoolSize = 0. I
have not changed these settings so they are the defaults. According to
the above article:
If the values of both RegistrySizeLimit and PagedPoolSize are 0x0, the
system calculates an optimal value for both entries. Typically, the
system sets the value of PagedPoolSize approximately equal to the
amount of physical memory on the computer, and it sets the value of
RegistrySizeLimit to approximately 33 percent of the value of
PagedPoolSize.
For Bob's 32GB setup, that means the maximum aggregate size for all
files that comprise the registry is 11GB. WOW! That's huge. That does
not include any slack space by the files within the file system, only
the allocated space within each file to hold the data (what actually
gets copied into memory).
There are some horror stories about installers that stored huge-sized
data blocks within the registry. One example was for a mouse "driver"
that stored its 32MB .pdf help file as a data item's value in the
registry. Some installers (and programmers) are very sloppy or don't
care about how they consume registry space. A user noted how to use
Nirsoft's RegScanner to find huge-size registry entries; see
https://superuser.com/a/1268082.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724881(v=vs.85).aspx
Generally, data consisting of more than one or two kilobytes (K)
should be stored as a file and referred to by using a key in the
registry rather than being stored as a value. Instead of duplicating
large pieces of data in the registry, an application should save the
data as a file and refer to the file. Executable binary code should
never be stored in the registry.
That article states, "The maximum size of a registry hive is 2 GB,
except for the system hive." There are only 2 real registry hives:
HKEY_USERS and HKEY_LOCAL_MACHINE. The others are pseudo-hives: they
are composites of subsections of the 2 real hives and as such consume no
more file space or memory (i.e., they are just different views into the
real hives but they are addressable separately via registry API calls).
There are some tools and Powershell scripts to get the current registry
size, or you could export it to see the size of the export file (its
size, not its size on disk which would include slack space in the file
system). Alternatively, you could check the sizes of the registry's
.dat files: %userprofile%\ntuser.dat (user's registry hive) and the
DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM files for the system hive
(under %windir%\system32\config). For me with a 4-year old Windows
setup with 8GB system RAM, the user hive file is 7MB and the system hive
files are 120MB, so 127MB total. That's 1.5% of of RAM for the registry
for its memory copy when the files get loaded into memory. For Bob with
his 32GB RAM setup, my registry size would be 0.38% of system RAM.
I just did a check of exporting the entire registry (go into
regedit.exe, select the root "Computer" node in the tree, and export all
of it) and the .reg file size was 323MB. Why the discrepency between
adding the file sizes for the user .dat and system .dat files? Because
the exported .reg file is a text file, not a binay database file. That
means a lot of wasted space to represent the keys and data items as text
instead of binary data within records in a database. Exporting the
registry to create a text file is not a good measure of the current
registry's size. Add up the user (ntuser.dat) and system files noted
above to get their aggregate file size.
The registry's files are loaded into system RAM and the registry API
calls access the memory copy. The registry is NEVER loaded into virtual
memory (which is the pagefile.sys disk file) because of the paging that
would restrict access to some parts of the registry and severely slow
down its access coming off of slow disk media (even for an SSD).