なぜプログレスバーはそれほど不正確なのですか？[閉まっている]

コンピュータとプログラミング言語は、決定論的で予測可能である傾向があります。ただし、特に操作が複雑な場合は、プログレスバーは逆になります。ワールドクラスのプロフェッショナル製品であっても、一部のプログレスバーは操作の実際の進捗を反映することがほとんどありません。4時間何もせずに1回のジャンプで10％から90％に移行するのを見てきました。いくつかの逆戻りも見たことがあります。予期しない余分な処理が発見されたことを示唆しています。

データベース操作、ネットワーク処理、および並列操作が存在する可能性があることは確かですが、これは何らかの方法で定量化でき、推定される割合であると思われます。結局のところ、操作を完了するために実行される命令の有限量がなければなりません。これは単に貧弱なコーディングですか、それとも進歩を表すいくつかの根本的な理由が難しいのですか？

これまでの一般的な回答に加えて、プログレスバーが機能しない私の分野の例をいくつか挙げます。

コンピュータ支援設計プログラム-熱分析または流体力学を実行するプログラムは、一般的にプログレスバーを使用するとひどい場合があります。彼らは前方、後方にジャンプし、一貫性のない手順を実行し、それらを監視することはほとんど役に立ちません。これは、これらのタイプのシミュレーションの反復的な性質と、収束を見つける必要があるためです。これは、進行状況バーではなく、反復v収束プロットで見るのが最適です。

複雑なシミュレーション-相互に関連する多くの要因がある複雑な環境をシミュレートするプログラムを作成しました。それは固定されたタイムライン用でしたので、これはプログレスバーがちょうどいい時間であると思いますか？私の場合、新しいタイムステップごとにシミュレーションが長すぎるため、プログレスバーは次第に遅くなります。シミュレーションの項目数に基づいて平均シミュレーションにかかる時間の正確性に近い別のメトリックを見つけました。ただし、プロセスバーが満たされない（シミュレーションが以前に停止する）か、100％から早い（シミュレーションが実行される）場合があるため、理想的ではありません。予想より長い）。

どちらの場合も、純粋な進捗状況の完全なバーは、事前に最大値を計算することができない（ケース1）か、線形ではないため、あまり使用されない（ケース2）

どちらも。事前にどれだけの作業を実行する必要があるかわからないため、操作にかかる時間を見積もることが難しい場合があります。時にはその単純で不正確な見積もり。

例：4つのファイルを同時にダウンロードしています。誰かが、各ファイルの大きさ、ダウンロードされた量、および各ファイルでダウンロードされた1秒あたりのメガバイト数を知っています。所要時間は簡単に予測できます。ただし、1つのファイルをダウンロードすると、他のファイルの方が速くダウンロードされることはわかっています。さらに3つのファイルがダウンロードされた後。最後のものは4倍速くダウンロードされます。これを考慮した進行状況バーを見たことがない。

例：大きなフォルダをコピーしています。プログレスバーは、1秒あたりXメガバイトをコピーすることを前提としており、メガバイト数と、これまでの平均速度を把握しています。問題は、「1秒あたりのメガバイト数」が非常に不正確であることです。実際には、ファイルごとにxミリ秒、さらにメガバイトごとにyミリ秒かかります。したがって、小さなファイルの多くは、プログレスバーが予想するよりもはるかに時間がかかります。

問題は、ソフトウェア開発者が気にするかもしれないことですが、彼らのマネージャーはあなたのコンピューターがクラッシュしない限りはそうではありません。

全体的な答えは、多くの場合、かかる時間を計算するには複雑すぎる（または不可能である）ことです。

場合によっては、必要な作業量をより正確に見積もるために、より多くの計算時間を費やすことが問題になる場合があります（たとえば、コピーされるファイルのより適切な分析を行うか、より複雑な計算を適用して、シミュレーションを完了します）。

また、かなり不確定な場合もあります。システムが新しいプログラムをインストールしているとき、多くの場合、インストールされていることを確認するために多くの依存関係があります。そして、一般的に、それぞれにかかる時間、およびそれらが次に必要とする可能性のある依存関係についての考えはありません。すべての依存関係が既にインストールされていて、30秒かかる場合もあれば、数十が不足していて数時間かかる場合もあります。特に、それぞれの状況が異なる場合には、公平な球場を与えるのは難しい。

さらに、システム上の他のドレインは、時間の経過とともに変化する可能性があります（ユーザーが何を行っているか、またはバックグラウンド/スケジュールされたプロセスのため）。

場合によっては、プログラマーがもう少し作業を行うと、見積もりが改善されることがあります。しかし、アプリケーションが実行できる実際の生産的なタスクを促進することと比較して、これがおそらくほとんどの開発者の最大の関心事ではないことは別の現実です。

結局のところ、今のところ、それはかなり頻繁に単なる線形推定であると思います-必要な基本タスクのいくつがプログラムを完了したかを見てください。ですから、それは確かに非常に大まかな見積もりになる傾向があり、一般的にはそのようなものとして考えるべきです。

---

本を読んでいるときが良い例です。
そして、
あなたはあなたが本を完成するのにどれくらいの時間がかかるかという考えが欲しいと決めました... あなたはページ数をチェックして、これまでのペースに基づいて簡単な見積もりを得ることができます。
読み始めたばかりの場合は、速度がまだ一般的ではない可能性があるため、これは不適切な見積もりになる可能性があります。しかし、かなり大まかな推測になることがよくあります。
または、本を読み飛ばして、画像の数とテキストの間隔の大まかな考えをつかむこともできます。そして、あなたが直面しているものについてのより良い考えを持っています。
しかし、たとえば、テキストの可読性が低下し、おそらく単純な文章から複雑な文章に移行する場合、それはまだ不十分な見積もりである可能性があります。または、注意をそらす別のタスクを予想できなかったために、見積もりが間違った方法で終わる可能性があります。
かなりの時間をかけてページごとに本に残っているものを注意深く分析することにより、すばらしい見積もりを得ることができます。同様に、カレンダーを確認し、さまざまな本の長期の過去の読書ペースのリストを保持することによって、同様にそれを改善することができます。
しかし、結局のところ、本を読むだけの遅延に見合うだけの時間がかかるのでしょうか。

---

私たちは皆、より良い指標を望んでいます。しかし、現状では、少なくともコンピュータ全体が標準化されたアルゴリズムの改善を開始し、「インテリジェントに」計量および動的な要素（方法など）を予測できるようになるまで、大まかな見積もりを行う必要があります。

そして、その上の進行状況バーは、おそらく現在5％でスタックしています。それがどうなるかを確認する必要があるだけです8-）

@ gnasher729の回答に、これが停止問題の決定不能性のもう1つの隠された結果であると付け加えます。

対話型計算の固有の予測不可能性は別にして、分離できるものでも実行時間（および「リズム」）があり、その予測可能性には一般的な方法では対応できない場合があります。

悲しいことに、プログレスバーはしばしば役に立たない比喩です。代替案は何でしょうか、あなたは尋ねるかもしれません。ユーザーが「内部」で何が行われているのかを認識している場合、インターフェースに意味情報を追加して、トレースモードのような実行に移行することもできます。そうでなければ、期待を減らす穏やかな雰囲気を作り出します。

私たちの制限を理解するようにユーザーを教育することは、長期的な3番目のオプションです。

進行状況バーは、経過時間/完了に必要な時間ではなく、完了したサブタスクの数に基づいて描画されます。

たとえば、操作Xに4つの異なるサブステップがあり、各ステップの最後に進行状況バーを25％増加するとします。1つのステップの実行に時間がかかる場合、説明した動作が見られる可能性があります。1回の実行で1〜90％、残りは1時間です。

時間ではなく1つの単位としてサブタスクの数を使用する背後にある論理は、後者は予測不可能であるということです。ファイルをダウンロードした場合でも、接続が切れてしまうため、時間を単位として利用できません。むしろ、進行状況の単位として必要な時間ではなく、ダウンロードされたバイト数を使用します。