> It's not that the registry grows large. It's because it accumulates cruft.
This seems to be the correct answer, but not for the reason you think ("outdated information"). The registry is a highly indexed database, because it needs to be quick at answering if say a low-level kernel-level driver needs something in real time for an operation. Many of those indexes are variations on Most-Recently-Used (MRU) caches. The more applications that make random queries to the Registry, the more those MRU caches churn and the more likely the MRU caches are full of small, one-off application data versus important stuff that needs to be queried as quickly as possible. (Over time Windows has seemed to work to compensate by changing indexing strategies, but at a high level a lot of the slow down issues with registry still boil down to index problems.)
The Registry wasn't intended to be a general application configuration store, per the original registry usage guidelines. Certainly that ship sailed.
(Also, the key problem with INI files was not that opening/reading them took a long time, it was the same centralization problem: almost every Windows 3.x application stored their INI in C:\WINDOWS for a number of dumb reasons. When Windows 9x started enforcing basic directory ACLs and not every program under the sun could read/write to arbitrary files in C:\WINDOWS, people scurried for the Registry as that seemed the closest to what they were already doing, squirreling config data in C:\WINDOWS for dumb reasons. It took a while for developers to realize they should just put config files in whatever format they prefer in %LOCALAPPDATA% or such like and stop trying to centralize them.)
In the Windows 3.1 days I had some interesting problems when importing data into an MS Access databases that would contain reports for our senior execs to read while offline (the web was not a thing back then) and import throughput slowed down to a near-halt after 30 megs of data or so. Our solution was to do the import in chunks, and defragment the database between them.
This seems to be the correct answer, but not for the reason you think ("outdated information"). The registry is a highly indexed database, because it needs to be quick at answering if say a low-level kernel-level driver needs something in real time for an operation. Many of those indexes are variations on Most-Recently-Used (MRU) caches. The more applications that make random queries to the Registry, the more those MRU caches churn and the more likely the MRU caches are full of small, one-off application data versus important stuff that needs to be queried as quickly as possible. (Over time Windows has seemed to work to compensate by changing indexing strategies, but at a high level a lot of the slow down issues with registry still boil down to index problems.)
The Registry wasn't intended to be a general application configuration store, per the original registry usage guidelines. Certainly that ship sailed.
(Also, the key problem with INI files was not that opening/reading them took a long time, it was the same centralization problem: almost every Windows 3.x application stored their INI in C:\WINDOWS for a number of dumb reasons. When Windows 9x started enforcing basic directory ACLs and not every program under the sun could read/write to arbitrary files in C:\WINDOWS, people scurried for the Registry as that seemed the closest to what they were already doing, squirreling config data in C:\WINDOWS for dumb reasons. It took a while for developers to realize they should just put config files in whatever format they prefer in %LOCALAPPDATA% or such like and stop trying to centralize them.)