I soon will have a folder with thousands of files, each file on the order of a few KB. I will need to transfer these across a Windows network from one UNC share to another. In general, is it faster to simply copy the files over en masse, or would it be faster to zip them up (e.g., using 7zip in fastest mode) and send one or a few large files? Or is there no difference in practice?
Add a comment
|
6 Answers
It is faster to transfer a single large file instead of lots of little files because of the overhead of negotiating the transfer. The negotiation is done for each file, so transferring a single file it needs to be done once, transferring n files means it needs to be done n times.
You will save yourself a lot of time if you zip first before the transfer.
-
1
-
5Consider that compression will take time, too. If your data cannot be compressed (e. g. JPEGs, ZIPs, JARs and other already compressed formats) you should only TAR them (or ZIP without compression). This will save CPU time for the pointless attempt to further compress your data. May 19, 2009 at 10:19
-
1That many small files will cause you a lot of pain - in between tiny packets and doing an SMB handshake for each one, zipping will probably shave a good 60% off your copy time.– user2278May 19, 2009 at 13:44
-
1
-
This answer is correct, but on Windows 7 (at least) there is a known bug where copying the exact same set of files on XP is much faster than on Windows 7: social.technet.microsoft.com/Forums/en-US/w7itproperf/thread/…– tboneApr 25, 2012 at 17:29
Jon Cahill is very correct, a single file will be faster. However it's worth keeping in mind that if there is any instability in the connection, individual files (or medium-sized groups in zip files) may be better, because if the transfer fails you'll have to start all over again, whereas with multiple files you will just have to re-do the last file started
answered May 19, 2009 at 6:31
-
6
Lots of little files will also be more expensive to write to the file system than a single large file. It needs to do things like:
- Check the file name is unique
- Write out the file table entry
As you get more and more files in a directory this can become quite costly. And each of these steps can add latency to the copy process and slow the whole thing down.
answered May 19, 2009 at 5:57
-
2I guess he's still going to need all the small files in the target system, so he'll probably have to extract the zip later on, i.e. the filesystem will still have to do the work. Sending the large file and unzipping will still be much faster than transferring all the small files over net, though.– BlaMMay 19, 2009 at 8:08
-
@BlaM, as I said in the answer it all comes down to latency. If network latency is added onto each CreateFile operation the total time could be much longer. If the copy is smart enough to concurrently create files perhaps it wouldn't impact the operation. May 19, 2009 at 23:51
The average packet size relative to average file size is probably critical here. With lots of small files you may find yourself sending out many tiny packets. Tiny packets still incur TCP overhead; you could wind up doubling the amount of traffic as a result.
Modern systems and even relatively ancient ones can send multiple files over a single TCP connection, avoiding the costs of that handshake.
Just what I've found, but if you want a faster transfer initiate the transfer from the local computer, and copy to the local drive.
Ie copy \computer1\myshare to c:\files\myshare, don't use a third computer and copy from \computer1\myshare to \computer2\mynewshare.
It's also worth remembering that the choice of protocol affects the overall time to complete - for example, to FTP files from one host to another, can be noticeably faster than using windows file sharing (of course, things like domain permissions and the like are also lost, but in some situations, this can be an acceptable trade off -- After all, these would also be lost by zipping/unzipping)
answered May 19, 2009 at 12:11
