You can only check timing before and after the click to
File.Copy; you cannot hook into the middle of transfer to update partial speeds. If this is all you want, you can use the class
System.Diagnostic.Stopwatch, which gives you the best accuracy:
https://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch%28v=vs.110%29.aspx.
If you want to measure the speed in the middle of copy of some big file, you would need to write your own file copy method, which can be easily done using the classes
System.IO.BinaryReader and
System.IO.BinaryWriter:
https://msdn.microsoft.com/en-us/library/system.io.binaryreader%28v=vs.110%29.aspx,
https://msdn.microsoft.com/en-us/library/system.io.binarywriter%28v=vs.110%29.aspx.
You can read and write data by blocks of some size and checkup the speed after each block. You should better be careful with that: you can easily compromise your performance. So, you may want to experiment with that, comparing with the speed of
File.Copy and trying different block sizes. Expect very high dispersion of statistics of the speeds, so repeat test many times and collect solid statistics, before making any conclusions.
There is on catch in timing:
you need to exclude the time of JIT compilation from your timing. This is a very important factor to take into account. And this is easy enough to do. Just keep in mind that if some code is executed for the very first time, it could not be JIT-compiled yet. So, start your timing with the call when all the methods have been already called before at least once.
See also:
http://en.wikipedia.org/wiki/Just-in-time_compilation.
—SA
Submit an article or tip