进度条等的实际时间估计

Question

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

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

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

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

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

---

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

---

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

我现在要做的是取上一步中某事所花费的平均时间（按类型分组并按例如文件大小、事务大小进行标准化的步骤）并将该平均值作为下一步的估计（再次：计入不同的类型和大小）。

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

Answer 1

我正在使用DREJ 对历史进展进行非线性最小二乘回归。 效果很好。

我使用数据库表来存储我的历史数据。我根据表中的最后 100 个条目重新构建了我的估算器函数。

我有关于识别速率决定变量的长期运行方法的注释。

YMMV，但下次估算时会考虑到这一点。

Answer 2

谢天谢地，我不是唯一一个！

我不知道有哪个库可以处理估算，但我可以亲自担保您的分析想法。我曾经实现了一个进度条，用于报告一个长而复杂的文件操作的进度（几个小文件正在被读取、处理，然后组合成一个更大的文件）。我让软件跟踪读取、写入和处理所花费的时间，然后相应地调整进度条。程序运行几次后，进度条会像丝绸一样平滑。没有停顿，也没有快速闪烁。

只要您的操作所花费的时间很容易衡量，这就是有效的。我对在下载进度指示器之类的东西上使用这种方法持谨慎态度，因为网络的速度是完全不确定的。

Answer 3

使用进度条的问题通常是一个过程需要多个不同的步骤。因此，如果我正在为软件更新创建进度对话框，我不会使用单个进度条，而是使用带有复选标记的任务列表，以便用户可以看到当前正在执行的任务。

如果任务花费的时间超过 10 秒，请在任务旁边放置一个进度条，以便他们可以看到工作正在完成并且不会过早中止。

下载更新
停止正在运行的进程
更新软件
配置软件
重启程序

个人任务很好，因为过去的表现强烈地预示着未来的表现。下载的前 10 秒可能会显示文件的其余部分需要多长时间。与更新本身相同。

较短的进程不需要进度条，因此在任何进程花费 10 秒或更长时间之前，甚至不要在任何进程上显示进度条。这样，快速系统上的用户只会看到每个任务上的复选标记，而在慢速系统上，用户会看到复选标记，如果它在任务上停留“太久”，他们会看到包含实际有用信息的进度条。

而且进度条并没有承诺后面的任务需要多长时间。

在底部有一个涵盖所有任务的最佳猜测的总体“估计剩余时间”非常有用，但我不会在进度条上显示。

进度条的意义在于它们是线性移动的。当他们跳跃和口吃时，这对用户来说非常令人沮丧 - 他们实际上没那么有用，并且在这种情况下提供了错误的信息。

为工作选择合适的工具。太多次选择了进度条，而实际上它是错误的工具。

-亚当

Answer 4

另一种（也是更简单的方法）是仅填充估计值和用户感知。

大多数进度条更多地用于 UI 响应而不是持续时间预测：用户需要得到反馈以确认程序没有停止 - 但不太关心完成时间。

如果我正在等待一项任务，并且它在 10 秒内完成了 50% - 当我需要另外 20 秒才能完成最后 50% 时，我会感到沮丧。

对于同样的任务，如果它在 30 秒内达到 50%，继续运行到 60% - 然后神奇地跳到 100% - 我很惊讶，但并不恼火。

如果任务真的很短或完全不可预测，一些动画循环也可以工作（浏览器加载图标、iPhone 等待动画等...）。

如果您确实需要准确性的几种情况 - 那么可能值得花一些时间在代码中以提高条形图的可靠性。

Answer 5

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

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

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

Answer 6

我认为问题不在于他们对步数的估计如此之多，而是经常使用错误的“步数”定义。在您的安装程序示例中，安装程序在 10 秒内从 0% 到 9%，然后在剩下的一个小时内完成，我看到当程序员决定计算要复制的文件数而不是字节数时会发生这种情况。

假设有 10 个文件，其中 9 个是 5K（自述文件、许可证、图标等），最后一个是 2Gig ISO，嗯，前 9 个复制速度非常快，最后一个复制速度很慢！计数文件是错误的计数，应该计数字节。问题是，如果您想计算字节数，那么您需要实现自己的复制例程，以便在复制大文件期间提供状态更新。实现自己的复制程序真的值得吗？

另一个问题是安装（像许多其他事情一样）是由许多可能很深的例程组成的。这些例程可以做很多事情，但它们很可能是通用例程，并且其中没有任何东西能够在更高级别上更新某些进度表。您需要重新实现一些常见的例程才能获得良好的进度信息。

至于稳健的估算器，我认为这真的很难。可以在配置文件中定义特定步骤，但您需要从安装过程的每个部分进行进度更新。此外，做这些事情的时间显然会因机器而异，所以无论如何你可能会走得很远。当然，一旦您在特定机器上完成安装，您可能会估计下次在该机器上的安装。 ;-)

Answer 7

如您所说，您可能有 100 个步骤，但每个步骤所花费的时间取决于他们所做的事情。

一种方法是按照任务的操作（删除、更改注册表值、下载、复制文件等）对任务进行分组，并为每个组分配一些关键属性：

• 适用哪些可监控的指标（复制速度、解包速度等）？
• 该过程的平均最坏情况率是多少？

然后你需要为整个工作建立一个你将要做什么的清单，例如：

1. 解压 100meg 文件（组：解压，值：100）
2. 复制出 120megs（组：复制，值：120）
3. 设置注册表值（组：注册表，值：25）
4. 清理（组：删除，值：100）

因此，您可以根据预设的平均最坏情况值计算出总体“估计”，但准确度的关键是在您了解该系统的速度时更新每个指标乘数每个任务。

微软花了十年时间才把它弄好，所以如果一开始不起作用，不要太苦恼=)