language-agnostic - 进度条等的实际时间估计

Question

我知道我不是唯一一个不喜欢进度条或时间估计的人，因为它们在软件中给出了不切实际的估计。最好的例子是安装程序在 10 秒内从 0% 跳到 90%，然后需要一个小时才能完成最后的 10%。

大多数时候，程序员只是估计完成任务的步骤，然后以百分比形式显示当前步骤/总步骤，而忽略了每个步骤可能需要不同时间完成的事实。例如，如果将行插入数据库，插入时间会随着插入行数的增加而增加(简单的例子)，或者复制文件的时间不仅取决于文件的大小，还取决于文件的位置。磁盘及其碎片程度。

今天，我问自己是否有人已经尝试对此进行建模，并且可能创建一个具有可配置的稳健估计器的库。我知道很难给出可靠的估计，因为外部因素(网络连接、用户运行其他程序等)发挥了作用。

也许还有一种解决方案，可以使用分析来设置更好的估计器，或者可以使用机器学习方法。

有人知道这个问题的高级解决方案吗？

<小时/>

与此相关，我找到了文章Rethinking the progress bar非常有趣。它展示了进度条如何改变对时间的感知，以及如何利用这些见解来创建看起来更快的进度条。

<小时/>

编辑: 我可以想出如何手动调整时间估计的方法，即使使用“估计器库”，我也必须微调算法。但我认为这个问题可以通过统计工具来解决。当然，估算器会在此过程中收集数据，以便为下一步创建更好的估算。

我现在要做的就是取上一步中所花费的平均时间(按类型分组并按文件大小、事务大小等标准化的步骤)，并将该平均值作为后续步骤的估计(再次:计数)不同类型和尺寸)。

现在，我知道有更好的统计工具来创建估算器，我想知道是否有人将这些工具应用于该问题。

Answer 1

本科生时，Julian Missig我进行了一项与哈里森等人不同的实验。纸。正如您可能对类项目所期望的那样，我们并没有真正获得足够的数据来做出强有力的声明，除了 5 秒的间隔之外，显示没有进度条实际上被认为更短。

因此，如果任务可能需要不到 10 秒的时间，最好根本不显示进度条。这并不是说您不应该显示任何反馈，但进度条可能只会让它看起来更慢。

如果您有兴趣，Julian 有 paper和 poster在他的网站上。