There’s no doubt that dragging and dropping files using Windows Explorer is a super convenient way to copy and move files. But the sad truth is that these transfers are pathetically slow compared to what modern 15GBps NVMe SSDs are capable of.
On many systems, 3GBps max is what you’ll see in the latest Windows 11 24H2. Want 8- to 9GBps file transfers? Read on.
Why are Windows Explorer transfers so slow?
I’m not privy to all the technical reasons, but I do know that the code uses only a single dedicated thread and queue even though it appears otherwise in the Windows performance monitor.
NVMe storage offers multiple queues that may of course be accessed by multiple threads.
Furthering the mystery is the existence of Microsoft’s command-line program Xcopy, which is roughly two to three times as quick as Explorer. Why? Don’t know. But my working theory is that someone using it at Microsoft decided to fix it. Good on ya’, mystery person.
As hinted at, Windows Explorer appears to use six cores of my Intel Core Ultra 225 CPU, while Xcopy only uses four, and the soon to be discussed FastCopy only two.
According to the author of FastCopy (Shirouzu, Hiroaki) Explorer looks like it’s using six cores because “thread affinity” isn’t implemented and the single process drifts across cores making it appear as if they are completely involved.
Note that I’ve been told that the Windows Server 2025 has a far superior NVMe driver. Perhaps it will make it into consumer Windows eventually. Wouldn’t it be nice. (Queue the Beach Boys).
What file transfer program should you use instead?
XCOPY
I’ve already mentioned Xcopy, and I use it extensively via batch files, but how many mainstream users want to open a command prompt to type in xcopy commands? Not many. Note that it’s not nearly as bad or as tedious as you might think once you’re used to it. But I liked punch cards, so…
Also, batch files will eliminate the drudgery of repeated operations. There are even command switches that facilitate sync and backup operations. Indeed, it’s a handy little utility for all file operations.
There are also a couple of graphic interfaces out there for Xcopy, but the ones I tested weren’t particularly compelling. If you know of one, by all means send it my way.
@echo off
echo %Time%
xcopy x:\48GB r:\48GB /E /J /Q /I
echo %Time%
pause
The Switches shown above: /E — Copies directories and subdirectories, including empty ones; /J — Copies using unbuffered I/O. Recommended for very large files. /Q — Do not display file names while copying; /I — If destination does not exist and copying more than one file, assumes that destination must be a directory.
Open a command prompt and type “Help xcopy” to see all of them.
Now for some bad news for you few who haven’t skipped over this section. I’ve heard tell that Microsoft might deprecate (remove) Xcopy in favor of Robocopy which offers far more options. Alas, in my testing of Robocopy, it wasn’t anywhere near as fast as Xcopy, and much more in line with Explorer. Maybe Microsoft just doesn’t want you to enjoy the full fruits of NVMe.
There are command-line switches for buffer size, etc. that might improve Robocopy’s performance, and Microsoft might optimize it at some point, but for now, I can only vouch for Xcopy.
FastCopy
If the command line holds no appeal for you, there’s another, much, much easier solution — FastCopy. And it’s free for personal use.
While not quite as convenient as Explorer drag-and-drop for quick operations, FastCopy does integrate into Explorer’s context menus and offers a very efficient (if not modern in appearance) graphical interface.
Simply select the appropriate FastCopy command from the context menu, choose the destination from the popup dialog, click on execute, and FastCopy takes care of the rest.
FastCopy was a bit inconsistent early on in my testing — sometimes no faster than Explorer, but at its best and as of version 5.10, it was extremely reliable — faster than Xcopy at times and fast all the time. Sweet. The early inconsistency remains a mystery and as it no longer holds, there’s no way to further troubleshoot.
Another reason to use FastCopy is a slew of options that turn it into a lean, mean file-syncing or backup machine. See the image above. It requires a fair bit of expertise and the documentation isn’t the best I’ve seen, but it’s exceedingly handy, and faster than just about any sync or backup program I’ve tested.
Exactly how fast are Xcopy and FastCopy compared to Explorer?
I found Xcopy to be universally 2 to 3 times faster than Explorer. As mentioned, FastCopy was mysteriously inconsistent in my first test sessions, but as of the latest sessions it had settled in at a most remarkable 3.5x pace.
Below are the transfer times between two PCIe 5.0 NVMe WD SN8100 SSDs mounted in a HighPoint 7604a 4-slot M.2 adapter card.
These results beg the questions: Why is Explorer so slow, Microsoft? And why aren’t all of us using Xcopy or FastCopy?
What transfer method should you use?
There’s no denying that Explorer is the handiest way to transfer files. Use it for small-fry, everyday operations. But if you’re doing remotely heavy-duty file transfers, look to FastCopy. Or Xcopy if you want to feed your inner nerd.
