なぜプログレスバーはそれほど不正確なのですか？

最初の考えでは、時間の正確な見積もりを生成するのはかなり簡単なはずです。結局のところ、プログレスバーを生成するアルゴリズムは、それが前もってする必要があるすべてのタスクを知っています…?

ほとんどの場合、ソースアルゴリズムは事前に必要な処理を知っています。しかし、各ステップを実行するのにかかる時間を決定することは、事実上不可能ではないにしても、非常に難しい作業です。.

すべてのタスクが同じように作成されていない

プログレスバーを実装する最も簡単な方法は、タスクカウンタのグラフィカル表現を使用することです。完了率が単に次のように計算される場合 完了タスク数/総タスク数. これは最初の考えでは論理的に理にかなっていますが、（明らかに）いくつかのタスクは完了するのにより長い時間がかかることを覚えておくことが重要です。.

インストーラーによって実行される以下のタスクを検討してください。

フォルダ構造を作成する.
1 GB分のファイルを解凍してコピーする.
レジストリエントリを作成する.
スタートメニューのエントリを作成する.

この例では、ステップ1、3、および4は非常に速く完了しますが、ステップ2は少し時間がかかります。そのため、単純なカウントで作業しているプログレスバーは非常に速く25％にジャンプし、ステップ2が機能している間少しの間停止し、その後ほぼ100％にジャンプします。.

この種の実装は実際にはプログレスバーの中ではかなり一般的です。なぜなら、上で述べたように、実装が簡単だからです。ただし、ご覧のとおり、不均衡なタスクが 実際の 残り時間に関連する進行率.

これを回避するために、いくつかのプログレスバーはステップが重み付けされている実装を使用するかもしれません。相対的な重みが各ステップに割り当てられている上記のステップを検討してください。

フォルダ構造を作成します。 [重さ= 1]
1 GB分のファイルを解凍してコピーします。 [重さ= 7]
レジストリエントリを作成します。 [重さ= 1]
スタートメニューのエントリを作成します。 [重さ= 1]

この方法を使用すると、ステップ1、3、および4が完了時にバーを10％移動し、ステップ2が70％移動して、プログレスバーが10％刻みで移動します。確かに完璧というわけではありませんが、このような方法は、プログレスバーのパーセンテージをもう少し正確にする簡単な方法です。.

過去の結果は将来の性能を保証するものではありません

私があなたに時間を計るためにストップウォッチを使う間、あなたが50まで数えるように頼む私の簡単な例を考えてください。あなたが10秒で25に数えるとしましょう。残りの数をさらに10秒以内にカウントすると仮定するのが妥当なので、これを追跡するプログレスバーでは残り10秒で50％完了していることがわかります.

あなたの数が25に達すると、しかし、私はあなたにテニスボールを投げ始めます。たぶん、これはあなたの集中が厳密に数を数えることからあなたの方法を投げられるボールを避けて動くのであなたのリズムを壊すでしょう。あなたが数え続けることができると仮定すると、あなたのペースは確かに少し遅くなった。それで今プログレスバーはまだ動いています、しかし停止しているか実際にはより高く登っているかのどちらかの推定された時間でずっと遅いペースで.

これのより実用的な例として、ファイルのダウンロードを検討してください。現在100 MBのファイルを1 MB /秒の速度でダウンロードしています。これは、完了予定時刻を判断するのが非常に簡単です。しかし、その75％の割合で、ネットワークの混雑が発生し、ダウンロード速度が500 KB /秒に低下します。.

ブラウザが残り時間を計算する方法に応じて、ETAは即座に25秒から50秒になります（現在の状態のみを使用）。 残りサイズ/ダウンロード速度または、おそらくブラウザは、ユーザに劇的なジャンプを表示せずに転送速度の変動を調整するローリング平均アルゴリズムを使用します。.

ファイルのダウンロードに関するローリングアルゴリズムの例は、次のようになります。

前の60秒間の転送速度は、最も古い値が新しい値に置き換えられます（たとえば、61番目の値が最初の値に置き換えられます）。.
計算目的の実効転送速度は、これらの測定値の平均です。.
残り時間は次のように計算されます。 サイズ残り/有効ダウンロード速度

そのため、上記のシナリオを使用します（簡単にするために、1 MB = 1,000 KBを使用します）。

ダウンロードから75秒後には、60個の記憶された値はそれぞれ1,000 KBになります。有効転送速度は1,000 KB（60,000 KB / 60）で、残り時間は25秒（25,000 KB / 1,000 KB）です。.
76秒（転送速度が500 KBに低下する）では、実効ダウンロード速度は最大992 KB（59,500 KB / 60）となり、残りの時間は約24.7秒（24,500 KB / 992 KB）になります。.
77秒時：実効速度=〜983 KB（59,000 KB / 60）、残り時間は約24.4秒（24,000 KB / 983 KB）.
78秒時：実効速度= 975 KB（58,500 KB / 60）、残り時間は約24.1秒（23,500 KB / 975 KB）.

ダウンロード速度の低下が残り時間の推定に使用される平均値にゆっくりと組み込まれるにつれて、ここにパターンが出現しているのがわかります。この方法では、ディップが10秒間だけ続いて1 MB /秒に戻った場合、ユーザーはその違いに気付くことはほとんどありません（予想される時間のカウントダウンで非常にわずかな機能停止のために節約します）。.

真鍮製タックへのアクセス - これは、実際の根本的な原因についてエンドユーザーに情報を中継するための単なる方法論です。

非決定的なものを正確に判断できない

最終的には、プログレスバーの不正確さは、決定論的ではない何かのための時間を決定しようとしているという事実に帰着します。コンピュータはタスクをオンデマンドでもバックグラウンドでも処理するため、将来どの時点でどのシステムリソースが利用可能になるかを知ることはほとんど不可能です。そして、タスクを完了するために必要なのはシステムリソースの可用性です。.

別の例を使用して、かなり集中的なデータベースの更新を実行するサーバー上でプログラムのアップグレードを実行しているとします。この更新プロセス中に、ユーザーは次にこのシステムで実行されている別のデータベースに要求の多い要求を送信します。サーバーリソース、特にデータベースのリソースは、アップグレードとユーザーが開始したクエリの両方に対する要求を処理する必要があります。これは、実行時間にとって相互に有害なシナリオです。代わりに、ユーザーは大きなファイル転送要求を開始する可能性があり、これもパフォーマンスを低下させる可能性のあるストレージスループットに負担をかけます。あるいは、スケジュールされたタスクがキックオフしてメモリ集中プロセスを実行する可能性があります。あなたはアイデアを得ます.

おそらく、日常的なユーザーにとってより現実的なインスタンスとして、Windows Updateまたはウイルススキャンを実行することを検討してください。これらの操作は両方とも、バックグラウンドでリソース集約型の操作を実行します。その結果、それぞれの進歩は、その時点でユーザーが行っていることによって異なります。あなたがこれを実行している間あなたの電子メールを読んでいるなら、おそらくシステムリソースへの要求は低くなり、プログレスバーは一貫して動くでしょう。一方、グラフィック編集をしているのであれば、システムリソースに対する要求ははるかに大きくなり、プログレスバーの動きは統合失調症になります。.

全体的に、それは単に水晶玉がないということです。システム自体でさえ、将来のどの時点でそれがどのような負荷になるのかを認識していません。.

最終的に、それは実際には重要ではありません

プログレスバーの目的は、進歩が確かになされており、それぞれのプロセスがハングアップしていないことを示すことです。進行状況インジケーターが正確であればいいのですが、そうでないのであれば通常はほんのわずかな煩さです。率直に言って、より多くの重要なタスクがあるので、開発者はプログレスバーのアルゴリズムに多くの時間と労力を費やすことはしません。.

もちろん、進行状況表示バーが即座に99％完了にジャンプした後、残りの1％を5分間待たせると煩わされる可能性があります。しかし、それぞれのプログラムが全体的にうまく機能しているのであれば、開発者がまっすぐ優先順位を決めていることを思い出してください。.