Reputation: 25983
Our .NET app copies large files, and needs to give the user feedback; so rather than use File.Copy
we read a chunk of one file and write it to the other, and display the progress after each chunk. Nothing out of the ordinary. But what's the right size of chunk to use, to give the fastest file copy, assuming the time to display the progress is negligible?
Upvotes: 3
Views: 1505
Reputation: 273264
A very large buffer will give you the best transfer speed but a coarse feedback. So it's a trade-off and it also depends very much on the hardware.
I did something like this a while back and settled on a 64k buffer, but you might want to experiment a little.
And whatever you pick, make sure it's a multiple of 512 (1 sector)
Upvotes: 2
Reputation: 74780
You should consider using win32 function CopyFileTransacted (Vista Only) or CopyFileEx (Windows 2000 and higher). These are provided by Windows and are optimized for speed.
I would recommend you to test your custom C# implementation performance and compare it to native File.Copy performance. If the performance is comparable (i.e. same order of magnitude) than go with your custom C# implementation. Otherwise it's better to use CopyFileTransacted or CopyFileEx function.
P.s. from here:
[return: MarshalAs(UnmanagedType.Bool)]
[DllImport("kernel32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
internal static extern bool CopyFileTransacted([In] string lpExistingFileName, [In] string lpNewFileName, [In] IntPtr lpProgressRoutine, [In] IntPtr lpData, [In, MarshalAs(UnmanagedType.Bool)] ref bool pbCancel, [In] CopyFileFlags dwCopyFlags, [In] KtmTransactionHandle hTransaction);
Upvotes: 2
Reputation: 814
Even when using larger chunks you can easily estimate the progress to give the user "faked" feedback. Depending on the application why don't you let the user set the size? Give the user option if he wants it :)
Upvotes: 0