CD起動の場合LoadImageに時間がかかる

[戻る]
VID 2015/08/18(火) 01:00:07
MFC、VS2012

アニメーションのため、10枚ほどのBMPを読み込んで起動するアプリを作成しています。

HDDからの起動ではほぼ待ち時間無しで起動しているのですが、
CDに焼いて起動しようとすると異常に時間がかかります。
どうも、LoadImageでBMPを読み込むのに時間がかかっているようで、
1枚あたり3秒程度かかっています。(画像は一枚200〜300KBほど)

CDの初回起動時のみの動作のようで、一度起動した後に
再度起動するとキャッシュ?に読み込まれているのか
HDDと同程度の速さで起動してきます。

BMPを多くするとさらに時間がかかってしまうので、
何とか起動を早くする方法は無いでしょうか?
※アプリの都合上、BMPは外部から読む込むものとさせてください。


試しにスレッドを立てて同時読み込みしてみましたが、
CDにアクセスのためか、余計に時間がかかってしまいました・・・

仲澤@失業者 2015/08/18(火) 15:18:12
あまり思いつきませんが、

1.ファイルエクスプローラが裏でアクセスする場合があります。
  エクスプローラは閉じておきましょう。
2.CD挿入をきっかけに起動するアプリがあれば止めておきましょう。
3.「PIO病」になっていないことも確認したほうが良いかもしれません。

しかし、CDは原理的にファイルのアクセスは遅いですね。
USBメモリの方がはるかに早いです。

瀬戸っぷ [E-Mail] 2015/08/18(火) 17:27:56
CDでは仕方が無い部分もあるかと思われますが……。
回転停止していた場合、スピンアップして読み込み可能になるまでにそれなりに時間が掛
かります。
# 実行ファイルの読み込みが先だって行われているハズなので、大丈夫…なはずなんです
けどねぇ。

>1枚あたり3秒程度かかっています。(画像は一枚200〜300KBほど)

今時等倍で動作しているとは思えませんが、
等倍の場合の転送速度は秒間150KB程度ですので、大きいファイルだと時間がかかるかも
知れません。
# 構造上ファイルが外周近くにある方が転送速度は上がるはず…ですが。
# (シークで差し引きがあるからなんとも…。基本、シーケンシャルに読み出す事が前提の
メディアですからねぇ…)
# http://www.way-on.com.tw/PCbasal/kiso/hikari3.htm
# CLVだと外周に行くにつれ回転速度を変化させる必要が……。


>BMPを多くするとさらに時間がかかってしまうので、
>何とか起動を早くする方法は無いでしょうか?
>※アプリの都合上、BMPは外部から読む込むものとさせてください。

BMPを圧縮して、テンポラリにBMPファイルとして展開、そちらから読み込む。というのは
駄目ですか?
読み込み=>展開=>テンポラリに書き出し
と手間が増えますが、元々遅い光学ドライブよりはマシではないかと……。

VID 2015/08/18(火) 23:00:45
お二方、ご回答ありがとうございます。

>仲澤@失業者さん
すべて問題無かったですが、アクセスが遅いままです。
USBメモリで配布出来たら楽だったんですけどね・・・


>瀬戸っぷさん
試しに、

1.アプリを起動(画面だけ表示)
2.スレッドで裏でBMP読み込み
3.アニメーション開始

としてみたのですが、アプリの起動は比較的早いのですが
やはりアニメーション開始までが時間がかかってしまいます。

時間を計測してみると、やはりスレッド内のLoadImageのところで時間がかかっていま
す。
CD読み込み可能になってからBMP読み込みを開始しても遅いみたいですね。

圧縮⇒展開からの読み出し〜は
HDDへのファイルコピーは行わないという前提で作っているので無理なのです。
案を下さったのにすみません。

K 2015/08/19(水) 11:21:31
> 圧縮⇒展開からの読み出し〜は
> HDDへのファイルコピーは行わないという前提で作っているので無理なのです。

LoadImage() は使えなくなるかもしれませんが、
HDD (ファイル) に書き出さずにオンメモリで処理すればどうでしょう?

VID 2015/08/19(水) 23:24:12
>Kさん
オンメモリで処理とは、具体的にどういう技術でしょうか?
MFCで実現可能そうですか?

K 2015/08/20(木) 11:28:57
> オンメモリで処理とは、具体的にどういう技術でしょうか?

「HDDに書くのはダメ」なら「書かずにメモリ上で処理すればいい」(のでは?)
というだけの話です。

> MFCで実現可能そうですか?

例えば zlib の uncompress() のプロトタイプは

extern int uncompress( Byte* dest, uLong* destLen, const Byte* source, uLong 
sourceLen);

こんな感じですから、圧縮した内容を source に置いて呼べば、それを展開した結果が 
dest に格納されます。
DLL ですから、普通に C/C++ から呼べます。

まぁ別に zlib にこだわる必要はありませんが。

AR 2015/08/21(金) 11:50:31
あまり参考にならないかもですが私の場合の事例です

アニメーション用に約100枚ほど画像を読み込んだ後にCImageListを生成していました
そこで生成したCImageListでWrite/Readメソッドを使い、1個のファイルとして保存/読
み出してI/O回数を減らす高速化ということをしたことがあります
もちろんCImageListは同じサイズ、同じ色数など制限がありますが、比較的に容易に実現
できるので条件が合うようなら試してみてください
アニメーションのようなパラパラ漫画的なものなら、ちょうどマッチすると思いますよ

aetos 2015/08/21(金) 11:59:04
圧縮しておけば、ディスク I/O を減らす効果はありますね。

画像の圧縮と言えば JPEG や PNG です。
多少の画像劣化を許容してもサイズを減らす方を優先するなら JPEG ですね。
で、どうやら、MFC なら CImage::Load を使えば、JPEG も PNG もそのまま読み込めるよ
うです。

https://msdn.microsoft.com/ja-jp/library/tf4bytf8.aspx

JPEG より圧縮率が高く、しかし MFC がサポートしていないフォーマットを採用したいん
だ、という場合は何か手を考えなければいけないでしょうけど。
まずは PNG や JPEG(画像の劣化具合と速度のバランスを図りつつ)で試してみて、許容
範囲に収まるかどうかを調べてみてはいかがでしょうか。

古いスレッドには追加発言できません。