When copying files there are two costs - fixed per-file cost (of opening/closing a file) and variable cost of bulk copying. If you track both, you can pass the measurements through basic linear regression and get a simple formula -<p><pre><code> ETA = A * number-of-file + B * number-of-bytes
</code></pre>
This can be further refined to accomodate the cost of file extension for larger file, the overhead of directory creation, etc, but in practice basic two-term model works really well.<p>There was an earlier post on HN on this, let me see if I can find it ... <i>edit</i> ... Nope, not HN. I was thinking of this - <a href="http://www.bvckup.com/support/forums/topic_show.pl?tid=101" rel="nofollow">http://www.bvckup.com/support/forums/topic_show.pl?tid=101</a>
I believe the prediction is made based on the estimated size of the copy and it doesn't take into account the number of items to be copied. As any seasoned computer user will tell you, a large number of small files takes longer to copy then a similar sized large file. When the migration wizard is copying a huge number of small files the transfer goes far slower than when it gets into your documents and other large items.
There are a couple of things Apple seems bizarrely bad at and a lot of them seem to involve networked file manipulation (Migration Assistant, Time Machine etc.) There seem to be network operations that have latencies orders of magnitude slower than they should be which brings down the performance of the entire application.
A bit frustrating, perhaps, but how often is migration assistant used by an individual user?<p>I would think it would be more important to get the estimate right for routine batch file copies. Obligatory reference to XKCD #612: <a href="http://xkcd.com/612/" rel="nofollow">http://xkcd.com/612/</a>