Registry Optimizations
The Configuration Manager makes a few noteworthy performance optimizations. First, virtually every Registry key has a security descriptor that protects access to the key. Storing a unique security-descriptor copy for every key in a hive would be highly inefficient, however, because the same security settings often apply to entire subtrees of the Registry. When the system applies security to a key, the Configuration Manager first checks the security descriptors associated with the key's parent key, then checks all the parent's subkeys. If any of those security descriptors match the security descriptor the system is applying to the key, the Configuration Manager simply shares the existing descriptors with the key, employing a reference count to track how many keys share the same descriptor.
The Configuration Manager also optimizes the way it stores key and value names in a hive. Although the Registry is fully Unicode-capable and specifies all names using the Unicode convention, if a name contains only ASCII characters, the Configuration Manager stores the name in ASCII form in the hive. When the Configuration Manager reads the name (e.g., when performing name lookups), it converts the name into Unicode form in memory. Storing the name in ASCII form can introduce significant savings in a hive's size.
Finally, over time a Registry hive can fragment. For example, the hive in Figure 1 is fragmented because it contains empty spaces. The Configuration Manager never tries to compact a Registry hive, but NT can achieve Registry compaction. When you use the Win32 API RegSaveKey to back up a Registry hive to another file (Emergency Repair Disk—
ERD—creation uses this API), the system strips the copy of all free space, effectively condensing the hive. To switch to the compacted hive, you use the RegReplaceKey or RegReplaceKey Win32 APIs, which the ERD restore function uses.
The End of the Tour
Win2K beta 3 contains no significant changes to the Configuration Manager or to the way NT manages Registry hives on disk or in memory. In fact, you can use regedt32's Load Hive capability to load Win2K Registry hives from an NT 4.0 system. However, Win2K beta 3 introduces significant memory and performance optimizations. First, key control blocks in Win2K don't store full key Registry pathnames, as happens in NT 4.0. Instead, Win2K key control blocks reference only a key's name. For example, a key control block that refers to \Registry\System\Control would refer to the name Control rather than to the full path. A further memory optimization is that the Configuration Manager uses key name control blocks to store key names, and all key control blocks for keys with the same name share the same key name control block. To optimize performance, the Configuration Manager stores the key control block names in a hash table for quick look-ups.
A second optimization is that the Configuration Manager stores frequently accessed key control blocks in the Cache Table, which Win2K configures as a hash table. When the Configuration Manager needs to look up a key control block, it first checks the Cache Table.
Finally, the Configuration Manager has another cache, the Delayed Close Table, for keeping key control blocks that applications close. The Configuration Manager would usually deallocate closed key control blocks but in Win2K keeps the blocks in the Delayed Close Table, in case an application needs to reopen a key it has recently closed. The Configuration Manager removes the oldest key control blocks from the Delayed Close Table as it adds the most recently closed blocks to the table.