I have seen excuse after excuse from Piriform's developer(s) why they cannot or should not enable / code Defraggler to execute multiple simulataneous deframentations on separate drives.
These excuses have included (not all on this thread):
1. Multithreading Defraggler would not result in a performance improvement since quote 'the bottleneck is the I/O (ie. physical drives):
1A. Answer for Single Drive with Multiple Selected Partitions: As other multidrive-capable defragmenters do, Defraggler could check the disk source of all the partitions selected by the user for defragmenting and then defragment them one-by-one-per drive but in parallel to other defragmentations on other drives.
2. Simultaneous defragmentation of multiple drives would not result in significant/any increase in performance due to Controller I/O Limitations:
2A: Answer for Single IDE Controller: All modern IDE controllers use Busmastering UDMA which provides 100 / 133 MB/s transfer rate per cable which is far faster than two physical hard drives [Master & Slave] can transfer data on that single cable with both drives at maximum linear sequential read speed - unless they are the now-rare IDE-SSDs - which since they are SSDs don't require defragmentation anyway.
2B: Answer for Multiple IDE Controllers: The only limitation on I/O in this case is the PCI/PCIe bus which is fully capable of carrying all data from parallel reads on multiple drives with tons of bandwidth to spare.
2C: Answer for a Single SATA Controller: Each SATA port is entirely separate with no cross-contention and provides 150/300/600 MB/s per port which is far more datarate than any mechanical drive can read at and faster than many SSDs's datarates. When the data gets to the controller chip it also travels in parallel paths or is merged into higher-clocked sequential lanes for transfer to PCI/PCIx/PCIe or via proprietary Southbridge-CPU links that many Intel boards now use. These links provide far more than enough datarate to handle parallel operations on multiple drives and indeed that is their exact purpose.
2D: Answer for Multiple SATA Controllers: Same answer as 2B.
Bus Data Rates:
PCI 32-bit x 33MHz: 133 MB/s (Common)
PCI 32-bit x 66MHz: 266 MB/s (Uncommon)
PCI 63-bit x 33MHz: 266 MB/s (Uncommon)
PCI 64-bit x 66MHz: 533 MB/s (Uncommon)
PCI-X: 1064MB/s (Uncommon)
PCI-X 2.0-1: 2132MB/s (Uncommon)
PCI-X 2.0-2: 4266MB/s (Uncommon)
PCIe v.1: 250 MB/s PER SEPARATE LINK
PCIe v.2: 500 MB/s PER SEPARATE LINK
PCIe v.3: 985 MB/s PER SEPARATE LINK
PCIe v.4: 1969 MB/s PER SEPARATE LINK
Parallel simultaneous defragmentation of multiple drives equals a massive speed improvement that exceeds by as many times as drive-independent selected partitions the equivalent one-at-a-time speed. A velocity improvement that increases in linear proportion to the number of drive-independent partitions selected for defragmentation.
I can offer an explanation why Defraggler's developer(s) have so far resisted the upgrade of this application to MSDD (Multiple Simultaneous Drive Defragmentation). It's due to Defraggler's legacy code which was written to defragment only one drive at a time.
Despite all the versions issued since the first, that engine has never been fundamentally altered. Certainly bugs were removed in newer versions. Definitely new capabilities were added to allow the defragmentation of USB drives for example. However, even the newest version of this software still uses the same single engine under the hood.
There is a way users can force Defraggler to defragment multiple drives simultaneously.
Notice that if you try to run two copies of Defraggler in an attempt to do parallel defragmentation, the second copy of Defraggler pops a window with the text: "Defraggler is already running.".
When Defraggler starts up it checks system memory space for another copy of itself and if it finds this copy it pops the dialog and clicking this dialog's OK button sends the second executable to self-termination.
Duplicating the Defraggler.exe executable then renaming it doesn't stop the detection, thus Defraggler is checking the Process Name in memory, not the process's image file on-drive.
Using Resource Hacker to change the renamed executable's string identifiers does not prevent the code from identifying a duplicate upon execution.
Disassembly will allow a code-trace to find both the method at tree-breakpoint where the check is performed. Then the check can be disabled thus allowing multiple copies of Defraggler to run in memory simultaneously.
This will be less work than further lobbying Defraggler's unresponsive developers to rewrite the obviously dated, shortsightedly single-engined code.