Why does using the /mt switch in robocopy cause it to pause before starting?

Question

Today, I learned that you can use the /mt switch with robocopy to make file transfers faster. I tried a few different options for /mt:#, including 1, 8, 17, 30, and 32. I found that 8 (the default) seemed to be the fastest for whatever reason.

I believe that /mt:1 is the same as not using /mt at all. But when I don't use /mt, the file transfer begins right away and I can see text scrolling by instantly. If I use the /mt switch, whether I put a number after it or not, and whatever number I use if I do, robocopy will get invoked, and displays the robocopy statement in the batch file for maybe 5-10 seconds and then executes (that's when I finally see text going by to indicate a file transfer).

I initially thought it could be that using the /mt switch means the batch file hangs for a few seconds while waiting for some multi-thread service or something. But I tried /mt:1, which should be the same as not using it, and it hangs just like when I specify any other number. The only time it starts file transfer right away is when the /mt switch is not used at all.

Obviously, I'm using /mt to make the script go faster. It only takes about 20-30 seconds depending on if /mt is used and what number I use, so every second counts in making this go faster. How can I get rid of the delay caused by using /mt? Pressing space or ENTER do nothing.

Here is what is being used:

robocopy "H:\LOS\DefaultCitrix\ChromeCitrix" "%userprofile%\Documents\ChromeCitrix" /e /w:1 /r:4 /mt:8

Answer 1

Generally, when something gets multithreaded, a portion of the job is handed to each thread. If the app wants to show progress, it has to collect status from each thread and show it to you. The more fine grained the detail, the more complex the process, and it doesn't really do anything good for you in terms of speed, to do all that interthread communication.

In a single threaded application, conversely, the work can be just dumped to the console whenever.

To keep it simple, the threads are probably only reporting back to the user interface when they finish a block of work.