Registry "Cleaning" is generally snakeoil. There can be uses for good cleaners (like CCleaner) when you are trying to solve a specific purpose (removing all traces of a sloppy graphics driver uninstall is a common use-case), but most of the time,
it is useless. According to Ed Bott:
I'd go a step further: Don't run registry cleaner programs, period. I won't go so far as to call them snake oil, but what possible performance benefits can you get from "cleaning up" unneeded registry entries and eliminating a few stray DLL files?
When you think about it, this really makes sense. A registry cleaner might find and clean out 50 or 100 or 200 "orphaned" entries left behind by a bad uninstaller that doesn't properly clean up after its source application (which is mostly what they do). Sure, those entries are loaded into RAM, and are unnecessary, but each key is
very small individually. And, by percentages, your registry might contain 500,000 individual keys. Removing 0.01% of the RAM used by the registry by "cleaning" out 200 keys isn't going to make a darn bit of difference anyone can see.
Registry Defragging is sometimes useful on a spinning disk, but is especially useless with an SSD. The only thing it can
ever help with is startup and shutdown times.
The registry is, in full, loaded into RAM and kept there throughout any login session in Windows. Any changes you make are writes to RAM, not to disk, and so is unaffected by fragmentation. Only when you login/logout are changes read-from/to disk (well, it also flushes changes to disk periodically, but this is only done when the disk is otherwise idle). So, even if your registry hive files are badly fragmented, fixing it will only impact those big login/logout read and write operations, after which, the whole darn thing is resident in RAM for all uses.
If you are on a slow disk, particularly one that is highly utilized (almost full states often result in heavier fragmentation), you can see some boot time benefits from defragging the registry (all that random access costs time). But think about the entire point of defragging. The idea is to take files that are broken up and stored in "hunks" spread all around the surface of the disk, and to shuffle the pieces around to store them contiguously. The reason to do this is because traditional spinning disks have much faster sustained read rates than they do random access rates (which requires moving the head around and then waiting for the platters to spin around to the right place).
As explained above, SSDs have near-instantaneous random access times.
Defragging does not help (and can hurt) an SSD, and regular defragging is just going to result in excessive write amplification, and can reduce the lifespan of your drive. Basically, the rule of thumb with an SSD should be "don't write to it when you don't have to". Not that you need to worry
that much, as most SSDs will die from component failures before a substantial enough portion of the NAND has exceeded its write-erase cycle limits (or will be so small by modern standards that they have out-lived their usefulness anyway). But you shouldn't do it
wastefully. It comes down to this:
When Random Access Times are instantaneous, there is no need to ensure that files live "together" on the disk anymore.In fact, even when you do this, the SSD doesn't actually store the files contiguously on the NAND. All SSD controllers are constantly shifting data around as you write it. Spreading writes across the available NAND as part of their wear leveling scheme, cycling over-provisioned capacity out for "used cells". Even more significant, SSD controllers internally stripe data across the internal NAND array
intentionally to spread the data across the various channels and improve performance (and they do parity bit calculations to provide for data integrity checking and recovery). Basically, inside that SSD,
the controller treats the NAND much like a RAID5 array, with the individual NAND chips playing the part of independent drives.
So, defragging them doesn't even actually accomplish the goal of "storing files contiguously", and even if it somehow did accomplish this by some miracle, it would
reduce the performance of the NAND array because the file would only be available to one of the drive's internal channels.
If you want to learn more about how SSDs work, and the future of the technology, you really can't go wrong with Ars Technica's recent monumental epic series on the subject:
1.
How SSDs Work2.
The Impact of Flash on Mobile Devices and Modern OSes3.
How Do You Make the Most of Your SSD?4.
The Future of Flash Memory