I have used Defraggler off and on for years. I have version 2.17 or so but I doubt 2.2 is any different. The CPU utilization is huge. Monstrous. In comparison to the Windows 7+ built in defragger.
Often it uses a full core of my CPU, a 3.45GHZ Core 2 Duo in order to defrag a 2TB bittorrent / storage drive. In other words, the algorithms used cannot keep up with the IO constraints of a laptop storage drive (Samsung M9T).
Also when analyzing, the CPU is often the bottleneck.
I have notice a lot of aftermarket defrag/optimization programs are very CPU heavy. It is quite obnoxious and should be a priority. But since you are not the only ones, I think O&O used to (haven't test the later versions) have this issue too, and I know Ultimat Defrag is CPU heavy, though the optimization techniques are more complex (sorting by name).
Please try to reduce it. It'll save time and power.
They do state in the latest release notes that memory usage has been improved so they do seem aware of the problem and are making attempts to address it.
Obviously that would need verifying on your PC to see how much, if any, improvement there is.
I'm thinking that, as you say, all/most of the other defrag programs in the game suffer from the same issue, then that would suggest some common, underlying, and probably unavoidable, reason.
Be it a Windows API or the sheer amount of number crunching required, I have no idea.
From the practical side of it, there should be very little need of the CPU, after the initial stage, to be an issue. Surely defragging is all about the disk I/O.
Good news, there is no CPU issue when you group select the top 100'ish files with the most fragments and process just those, then resort for the top 100'ish largest files and do those.
Thanks for the reply! 3 years later, I am running Defraggler 2.21.993 64-bit on Windows 8.1 on the same machine in the OP. This time on my 250GB SSD. 13% fragmentation. Started it about 4 hours ago. Over 3 hours of 1 core CPU usage now, 29% done on a complete defrag cycle (not quick). Over 350MB of RAM used.
Very CPU constrained. If this was running on a new Intel Ice Lake (10th gen) or AMD Ryzen 2 CPU at 5GHZ I would guesstimate it would be about 4x faster but would still be CPU bottlenecked some times.
I did just now stop the defrag and select around the top 25 most fragmented files and it successfully completed that in about 15 minutes. Now I am doing a Full defrag (12% fragmented) again. I'll edit or reply again when it finishes.
Is there a way to utilize SSE instructions to optimize the computation?
EDIT: First impressions, still going to take 'forever' to complete.
EDIT: Took about 5-6 hours to complete with 3+ hours of CPU time in task manager.
I have to ask the obvious question - why are you defragging your SSD?
due to the physical nature of how SSD's use NAND cell memory and the near-instantaneous access speeds between the memory blocks, there is simply no benefit to gain and a lot of unnecessary I/O to loss when using DF on SSD's.
Very small effect on the life of the SSD. I do it only a few times a year. Reduces CPU overhead when accessing fragmented files. And performing this eliminates I/O bottleneck for this experiment so it is clear the process is CPU constrained.
Ridiculous CPU usage when defragging mechanical drives as well.
One has to ask that if defraggler (and other aftermarket d/f's) are cpu heavy why don't you use Windows defragger? In Win 8 onwards with standard settings you will get a monthly defrafg of your HDD and SSD drives anyway if certain conditions are met. Sometimes Widows can look after itself quite well.
Windows' built-in defragger tends to not produce good results when dealing with mechanical drives mostly filled with multiGB files. And refuses to defrag an SSD.
You should never defrag an SSD. Fragmentation on an SSD doesn't matter since the file access is quick no matter how fragmented the files are. If you fragment an SSD it will only kill the SSD faster. This is why defrag software refuse to defrag SSDs. It's to keep the user from making a bad and costly mistake.