Origin of a legend
The “registry bloat slows PC” claim made sense on spinners in 2002: hives mapped sequentially, seek time mattered. Modern Windows memory-maps hive views; the working set your session touches is a few hot subtrees, cached. Benchmark attempts on XP-era hardware failed to find differences beyond noise; nothing has gotten truer since.
What DOES degrade with size
- Enumeration APIs on mis-ordered huge trees — specific code paths in tools that walk HKLM unbounded, worse on loop iteration logic than on the hive contents;
- Install-time MSI lookups in polluted Installer keys — the symptoms that “registry cleaning” pretends to treat are installer cache rot, not hive size;
- Hive FILE corruption recovery time — big file, longer chkdsk-flavored operations after a crash.
Keep the signal, drop the noise
Modern treatment: bounded, per-application auditing of the keys a tool actually writes (see our write pattern), explicit idempotence from known-documented defaults, and no touch of Installer/Components subtrees. Focus on what you changed, not how much stuff is in the file system you can't empty anyway.
ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.