进度条的现实时间估计等

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

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

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

也许还有一种解决方案使用分析来建立更好的估算器,或者可以使用机器学习方法.

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

与此相关,我发现文章重新思考进度条非常有意义.它显示了进度条如何改变时间感,以及如何使用这些洞察力创建似乎更快的进度条.

编辑:我可以想办法如何手动调整时间估计,即使使用"估算器库",我将不得不微调算法.但我认为这个问题可以用统计工具解决.当然,估算器会在流程期间收集数据,以便为后续步骤创建更好的估算值.

我现在所做的是采取上一步所采取的平均时间(按类型分组的步骤,并通过例如文件大小,交易大小进行标准化),并将此平均值作为后续步骤的估计值(再次:计算不同类型和大小).

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

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

因此,如果任务可能比10秒短,那么最好不要显示进度条.这并不是说您不应该显示任何反馈,但进度条可能只是让它看起来更慢.

如果你有兴趣,朱利安在他的网站上有纸和海报.

谢天谢地,我不是唯一一个!

我不知道有一个处理估算的库,但我个人可以保证你的分析想法.我曾经实现了一个进度条,用于报告长而复杂的文件操作的进度(正在读取,处理几个小文件,然后组合成一个更大的文件).我让软件跟踪读取,写入和处理所花费的时间,然后相应地调整进度条.程序运行几次后,进度条会像丝绸一样平滑.没有暂停,没有快速的昙花一现.

只要您轻松测量操作所需的时间,这就可以正常工作.因为网络的速度完全不确定,我会对下载进度指示器这样的方法使用这种方法持谨慎态度.