3

ETC = 「完了予定時刻」

ループを実行するのにかかる時間を数え、ユーザーに、プロセス全体にかかるおおよその時間を示すいくつかの数値を示しています。これは誰もがときどき行う一般的なことだと思います。従うべきガイドラインがあれば教えてください。

現時点で使用している例を次に示します。

int itemsLeft; //This holds the number of items to run through.
double timeLeft;
TimeSpan TsTimeLeft;
list<double> avrage;
double milliseconds; //This holds the time each loop takes to complete, reset every loop.

//The background worker calls this event once for each item. The total number 
//of items are in the hundreds for this particular application and every loop takes
//roughly one second.
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
    //An item has been completed!

    itemsLeft--;
    avrage.Add(milliseconds);

    //Get an avgrage time per item and multiply it with items left.
    timeLeft = avrage.Sum() / avrage.Count * itemsLeft;
    TsTimeLeft = TimeSpan.FromSeconds(timeLeft);

    this.Text = String.Format("ETC: {0}:{1:D2}:{2:D2} ({3:N2}s/file)", 
        TsTimeLeft.Hours, 
        TsTimeLeft.Minutes, 
        TsTimeLeft.Seconds, 
        avrage.Sum() / avrage.Count);

    //Only using the last 20-30 logs in the calculation to prevent an unnecessarily long List<>.
    if (avrage.Count > 30) 
        avrage.RemoveRange(0, 10);

    milliseconds = 0;
}

//this.profiler.Interval = 10;
private void profiler_Tick(object sender, EventArgs e)
{
    milliseconds += 0.01;
}

私はキャリアを始めたばかりのプログラマーなので、この状況であなたが何をするのか知りたいです。私の主な懸念は、ループごとに UI を計算して更新するという事実ですが、これは悪い習慣ですか?

このような見積もりに関して、すべきこと/すべきでないことはありますか? 毎秒更新する、10 ログごとに更新する、UI を個別に計算して更新するなど、それを行うための好ましい方法はありますか? また、ETA/ETC が良い/悪い考えになるのはいつですか。

4

2 に答える 2

4

プロセスにかかる時間の見積もりに関する実際の問題は、ワークロードの定量化です。それを数値化できれば、より正確な見積もりを作成できます

良い見積もりの​​例

  • ファイル システム I/O またはネットワーク転送。ファイル システムのパフォーマンスが悪いかどうかを事前に把握し、処理する合計バイト数を定量化し、速度測定できます。これらを取得し、転送したバイト数を監視できるようになると、適切な見積もりが得られます。ランダムな要因が見積もりに影響を与える可能性があります (つまり、その間にアプリケーションが開始されます) が、それでも有意な値が得られます

  • 大きなストリームでの暗号化。上記の理由によります。MD5 ハッシュを計算している場合でも、処理されたブロックの数、処理されるブロックの数、および合計を常に把握できます。

  • アイテムの同期。これは少しトリッキーです。単位あたりのワークロードが一定であると仮定できる場合、または差異が小さいか重要でない場合にアイテムの処理に必要な時間を適切に見積もることができる場合は、プロセスの別の適切な見積もりを行うことができます。メールの同期を選択する: メッセージのバイト サイズがわからない場合 (それ以外の場合はケース 1 に該当します)、一般的な慣行ではメールの大部分がまったく同じサイズであることがわかっている場合は、同期にかかった時間の平均を使用できます。処理されたすべての電子メールをダウンロード/アップロードして、1 つの電子メールの処理にかかる時間を推定します。これは 100% のケースで機能せず、エラーが発生する可能性がありますが、大規模なアカウントでは進行状況バーが引き続き表示されます。

一般に、数値がわかっている均一なプロセスがある場合は、ETC/ETA (ETA は実際には操作が完了する予定の日付と時刻です) を適切に見積もることができます。同質性は、作業項目を処理する時間が他の作業項目と同等であることを認めます。つまり、前の項目を処理するのにかかった時間は、将来の見積もりに使用できます。数値は正しい計算を行うために使用されます。

悪い見積もりの​​例

  • サイズが不明な多数のファイルに対する操作。今回は、処理 (ダウンロードなど) するファイルの数だけはわかっていますが、ファイルのサイズは前もってわかりません。ファイルのサイズの変動が大きくなると、問題が発生します。ファイルの半分をダウンロードした後、これらが最小で合計バイト数の 10% に達した場合、半分に達したと言えますか? いいえ!プログレス バーが 50% まで急速に成長し、その後非常にゆっくりと成長しているのがわかります。

  • 異種プロセス。たとえば、Windows のインストール。@HansPassant が指摘したように、Windows のインストールは、悪いよりも悪い見積もりを提供します。Windows ソフトウェアのインストールには、ファイルのコピー (推定可能)、レジストリの変更 (通常は推定されない)、トランザクション コードの実行など、いくつかのプロセスが含まれます。本当の問題は最後です。カスタム インストーラー コードの実行を含むトランザクション プロセスについては、以下で説明します。

  • 汎用コードの実行。これは決して見積もることができません。コード フラグメントには、条件文が含まれます。これらの実行には、コードの外部条件に応じてパスを変更することが含まれます。これは、たとえば、プリンターがインストールされているかどうか、ローカルまたはドメイン アカウントがあるかどうかなどによって、プログラムの動作が異なることを意味します。

結論

ソフトウェア プロセスの所要時間を見積もることは、不可能ではなく、正確な/* deterministic * タスクでもありません。

  • コードフラグメントの場合でも、コードのモデルを見つけることができるため、不可能ではありません (例として LU 分解を選択します。これは推定される可能性があります)。または、コードを再設計して、最初に分岐条件を決定する推定フェーズと、事前に決定されたすべての分岐が行われる実行フェーズに分割することもできます。ほとんどのコードは、分岐を前の条件の結果として判断します。つまり、分岐を推定するには、実際にコードを実行する必要があります。にわとりとたまごのサークル

  • それは決定論的なプロセスではありません。コンピューター システム、特にマルチタスクが推定プロセスに影響を与える可能性のある多くのランダムな要因の影響を受ける場合。プロセスを実行する前に正確な見積もりを得ることはできません。せいぜい、外部要因を検出してプロセスを再推定できます。プロセスの終わりに近づくと、見積もりとプロセスの実際の期間の間が数学的にゼロに収束します (lim [x->N] |est(N) - real(N)| == 0、N はプロセスforkです)間隔)

于 2013-05-13T12:19:18.353 に答える
2

ETC が Etcetera を意味しないことを説明しなければならないほどユーザー インターフェイスがわかりにくい場合は、それは間違っています。すべてのユーザーはプログレス バーの機能を理解していますが、役に立ちません。

不正確なプログレス バーほど煩わしいものはありません。特に、迅速な仕上げを約束しているが、配信しないもの. 根本的に壊れているものの良い例として、Windows のインストーラーによって表示されるプログレス バーを挙げます。追求すべき実装の輝かしい例ではありません。

プログラムのインストールにかかる時間を前もって推測することはまったく不可能であるため、このような進行状況バーは壊れています。ファイル システムのパフォーマンスは非常に予測不可能です。これは、実行時間の見積もりに関する非常に一般的な問題です。より優れた UI モデルは、ビデオ プレーヤーや Windows 8 の多くのプログラムで見られる回転するドットです。または、一般的な ProgressBar コントロールでサポートされているマーキー スタイルです。「私は死んでいない、それに取り組んでいる」というフィードバックだけです。砂時計カーソルでさえ、悪い見積もりよりはましです。ユーザーが本当に興味を持っていない技術的なことを超えて報告する何かがある場合は、それを表示することを躊躇しないでください。処理したファイル数やダウンロードしたキロバイト数などです。数値の実際の値はあまり役に立ちません。

于 2013-05-13T10:46:07.020 に答える