这种方法是否适用于计算复制文件的时间，是否有更好的方法？ [英] Would this method work for calculating time to copy file and is there a better way?

问题描述

我正在用C＃编写一个应用程序，它将一些文件从一个文件夹复制到另一个文件夹，我需要一种方法来计算复制它的剩余时间，然后在进度条中显示它。这会有效吗？：



复制文件的1个字节然后{将该时间乘以文件副本剩余的字节数所需的时间。将该总时间添加到DateTime.Now以获取将来理论上将被复制并将其转换为百分比并将其显示在进度条中的时间。}（重复花括号中的部分，留下的字节数为每次复制的字节数增加时复制）



但这对于小文件来说可能不太好，这些文件是我复制的大部分文件都可能被超越通过实际复制文件。这是计算复制文件所需时间的好方法，如果没有，我还能做什么？谢谢你

I am writing an application in C# and it copies a few files from one folder to another and I need a way to calculate the time remaining to copy it over and then display it in a progress bar. Would this work?:

Time how long it takes to copy 1 byte of the file and then {multiply that time by the number of bytes left to copy of the file. Add that total time to DateTime.Now to get the time in the future when it will theoretically be copied and convert it to a percentage and display it in the progress bar.} (repeating the section in curly braces for the number of bytes left to copy each time the copied byte count increases)

But this may not be good for small files which are what most of the files I am copying are and it may be overtaken by the actual copying of the file. Is this a good way to calculate the time left to copy a file and if not what else could I do? Thank you

推荐答案

我过去做的方式就是按文件来做。您可以获取要复制的文件数，每次完成文件时都会重新计算所花费的时间以及剩余文件所需的时间。



如果你想按大小做这个，你必须平均超过1个字节的复制，然后增加一些时间的开销。例如，您可以测量复制1Kb所需的时间，然后将其乘以要复制的Kb总数，并为文件系统开销增加10％的时间。您需要重新计算每次复制X kb后所需的时间（例如，每10kb后重新计算一次）。



没有一种真正准确的方法可以做到这一点，即使MS无法做到正确（任何看过在资源管理器中复制文件的人）。您必须经常重新计算。

The way I've done it in the past is to just do it by file. You can take the number of files to be copied and each time you complete a file recalculate how long it took and how long it will take for the remaining files.

If you want to do this by size, you would have to average out more than 1 byte of copying, then add some overhead to the time. For example you can measure the time it takes to copy 1Kb, then multiply that by the total number of Kb's to be copied, and add maybe 10% more time for file system overhead. You will want to recalculate the time required after every X kb's copied (for example, recalculate time after each 10kb).

There isn't a real accurate way to do this, even MS can't get it right (by anybody who's watched the time copying files in Explorer). You have to recalculate often.

文件以块（例如每次4K）写入磁盘，并具有自动缓冲功能。因此，写一个字节不会告诉你任何事情。



我建议您对增加大小的文件进行基准测试，不要在文件上使用进度条比方说，短于2/10秒。对于其他人，请按照这个大小的步骤更新进度条。

Files are written to disk in blocks (say 4K at a time), with automatic buffering. So writing a single byte tells you nothing.

I'd suggest that you benchmark full write of files of increasing size and do not use the progress bar on the files that take, say, shorter than 2/10th of a second. And for the others, update the progress bar in steps of that size.

不幸的是，绝对没有办法以任何合理的准确度预测这种操作的时间。当您使用任何Web浏览器的某个下载管理器显示百分比和预计完成时间时，您可以轻松地看到这种不准确性。通常情况下，预期的时间会来回摆动和强制，从几秒钟变回几小时后退。原因有很多：流量和操作环境的变化，下载的数据块会改变其典型大小（比如，长文件会被一组很小的文件改变），等等。



当您在同一台机器上复制文件时，情况要稳定得多，但类似因素（流量除外）仍在使用中。



您所能做的就是通过获取已经复制的部分时间和已复制数据的百分比来估算剩余时间。看到估计非常不准确并不奇怪。如果您在使用资源管理器或任何其他文件管理器复制文件时看到估计值有多么不准确，我可能会感到宽慰。在这方面有很多关于微软的笑话;你听到了吗？



对于计时，最好使用 System.Diagnostics.Stopwatch 代替：

http：// msdn .microsoft.com / zh-CN / library / system.diagnostics.stopwatch％28v = vs.110％29.aspx [ ^ ]。

-SA

Unfortunately, there is absolutely no way to predict the time of such operation with any reasonable accuracy. You can easily see this inaccuracy when you use some download manager of any Web browser showing percentage and expected time of completion. Often, expected time is oscillating back and forth back and force, changing seconds to hours and back. There are many reasons for that: traffic and operational environment changes, the chunks of data being downloaded change its typical size (say, long files are changed by a set of many very small ones), and so on.

When you copy files on the same machine, the situation is much more stable, but similar factors (except traffic) are still in play.

All you can do is to estimate remaining time by getting the time of already copies part and the percentage of already copied data. Not be surprised to see that the estimate is very inaccurate. I might feel some relief if you see how inaccurate is the estimate when you copy files with Explorer or any other file manager. There are multiple jokes about Microsoft in this regard; did you hear them?

For timing, it's always better to use System.Diagnostics.Stopwatch instead:
http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch%28v=vs.110%29.aspx[^].

—SA

这篇关于这种方法是否适用于计算复制文件的时间，是否有更好的方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！