作業量を計算する方法とは？

Question

こんにちわ。

やりたいこと

インストーラーなどでよく見る**[現在○％][残り○％]**表記。
これをプログラムで再現しようとしたとき、どのような方法を取るのが最適でしょうか？

作業内容は、自作の処理と、プログラム言語に付属している画像読み込み等の自分では手が出せないであろう処理の2つ。

案

• 1.時間で動かして、最後をごまかす
  自作の処理なら処理内容や何かしらの基準からの予測。

　画像読み込みならサイズから予測して、想定より少し遅い時間でカウントアップ。
最後は100％に達してなくても、作業が終わったなら無理やり100％にして終わらせます。

• 2.1行ごとにカウントする

　自分で作ったものならステップ数がわかっているので、手動でカウントして、現在完了した個数から％を出します。
ステップ数が自動でカウントできるならそれがよいのですが、よい方法が見つかりませんでした。

インストーラーは、2が近い感じでしょうか？
1つ1つの作業時間を見ずに、作業個数で％を割り出しているように見えます。
もちろん、物によるでしょうけども。

条件

考え方の基礎が知りたいので、言語は限定していません。
でもJavaやPythonで知ることができるなら是非とも知りたいです。

---

以上です、よろしくお願いします。

Answer 1

自分では手が出せない処理についてです。外部API呼び出しとか。
これは終了時間が見通せないので通常はパーセンテージが出せません。
それでも進行状況バーを出そうとしたらどうするか？

https://qiita.com/mono0926/items/ead7c576170277a5e83d

以前、「ランダムに進行状況バーを進めると非常にそれっぽい表示になる」というノウハウが紹介され話題になっていました。

進行状況バーの目的がユーザーを不安・不快にさせないことである場合、正しさとは別のところに答えがあるのだなと。

Comments

[sponge_yukari]

回答ありがとうございます。
フリーズしたように見せない点を重視して、後は待ってもらうしかなさそうですね。
計りようがないということが知れただけでも助かりました。

ランダム表示についてですが「表示は適当でもいいけど、処理が終わったのなら即座に返すべき」という考えが強かったので、考えていませんでした。

Answer 2

プログレスバーの考え方はMSDNが詳しい気がします。

進行状況バー

基本的にはユーザのストレスを軽減するためのものなので、制約と効果で実装方法などを以下から選択すればよいかと。（案１と案２）ですね。

完了した処理のおおよその割合を示すバー (確定型) と、単に処理が進行中であることを示すバー (不確定型) があります。

適当にやるとストレス軽減のためのプログレスバーがストレスになるというのもあるみたいです。

• 時間
• 計測可能な指標
• チェックポイント（作業工程のような）

このあたりから、要件をすりあわせていけばいいかなぁ。

4秒超えたらプログレスバーという記事もあります。
なんでプログレスバーってあんなにいいかげんなの？も面白かったです。

Comments

[sponge_yukari]

回答ありがとうございます。
MSDNの内容が非常に詳しくて参考になりました。
やはり作業の重量が計りにくいものは、何かしら適当にやるしかなさそうですね。

Answer 3

文字通り「％」でいいなら、基準値を適当に決めてやればいいんじゃないですかね。

画像読み込みなら、
全ての画像の個数 ÷ 処理済みの画像の個数でもいいし、
全ての画像のサイズ合計 ÷ 処理済みの画像のサイズ合計でもいいし、
全体個数を元にした％と現在処理中ファイルのサイズを元にした％の２つを併記でもいい。

自作プログラムなら行ごとでもメソッドごとでも、
やりやすい方で「全体の数」と「現在の数」を設定すればいい。

あるいは「（内部処理はちゃんと動いているが）画面上の％が一向に進まない」という表示はダメ！ということなら、時間予測も必要になってくるかもしれない。

なのでやっぱり結局は仕様次第、要件次第です。

言語問わずとのことなので、ご参考までに。

Comments

[sponge_yukari]

回答ありがとうございます。
自分で基準を決めて、それっぽく見せるしかなさそうですね。
こだわり始めると、途中でこのシステムを追加するには非常に手間がかかるものができそうです。

Answer 4

物によるかな？たとえば大量のＤＢレコードを読みたいとか、この場合にはselectでデータを取得する前に、
抽出件数を最初に抑えて、処理したレコード数に対して計算したり、大きいサイズdos形式などのファイルを読む場合には、そのファイルサイズを取得してレコード読み込み件数から読み込みバイト数を計算したり、
複数の処理がある場合には、その進捗から算出したりですね！

Comments

[akirafudo6]

１分以上だんまり（ＡＰからの応答）がないと、ＯＳでそのＡＰをウィルスと認識されます。ってのが
本音かな？

[sponge_yukari]

回答ありがとうございます。
select前に件数把握可能なんですね？
SQLをそこまでやったことないので知りませんでした。
DBを使うということ自体、失念しておりました。

SQL発行に時間がかかるケースというのはあんまりないイメージで、時間がかかるのはその後のプログラム側での処理かなと思っています。
SQL発行後なら予測時間は立てられるはずなので、まだ楽な部類ではありそうです。

[akirafudo6]

>select前に件数把握可能なんですね？
　こんなやつです。実際にデータを検索するのではないので、応答が速いです。
　 SELECT COUNT(*) AS CNT FROM scm.tblname;
　このほかに、もともとの統計情報（ディレクトリ）から持ってくる方法もありますが件数自体が曖昧な　ためあまり使うことはないと思います。

[sponge_yukari]

>SELECT COUNT(*) AS CNT FROM scm.tblname;
Countによる件数検索なんですね。
それほど複雑なSQLではないのであれば、大体の場面で使えますね。