或るプログラマの一生

その１の続き。

1フレームごとに時間を計測しようとするからマイクロ秒精度のタイマーが必要になってダメなんじゃないか、というのはある程度はその通りで、映像ファイル全体を処理する CPU 時間を計測する（もちろんフレームごとの CPU 使用率は計測できない）ことにすれば計測精度に関しては「だいぶマシ」になりますが、これにも問題がたくさんあります。

まず、映像全体を処理する時間を測る場合、コーデック以外の処理も計測対象に含まれてしまいます。一番影響が大きいのはファイルの読み込みでしょうか。vctest ではこのあたりを回避するため、コーデックを呼び出す直前に時刻を取得し、コーデックから処理が戻ってきたらまた時刻を取得して差を取る、という方法で経過時間を取得しています。

コーデック以外の処理が計測対象に含まれないようにするために、例えばファイルを前もって全部メモリに読み込んでから処理しようとすると、ファイルサイズ分の実メモリが必要ですし、読み込んだデータがメモリからスワップアウトされないようにロックをかける VirtualLock() Win32 API は仮想メモリ空間を対象とするので、32bit プロセス内ではおおむね 2GB までの映像ファイルしか扱えないことになります。（64bit プロセスの場合はこの点に関してはほぼ無問題）

さらに、これだとエンコードとデコードを分けて計測することができません。分けて計測するには、まずエンコードを終わらせてからデコードを始めることになり、エンコード結果を置いておくためにまたメモリとアドレス空間が必要になります。32bit プロセスだともう 1GB の映像ファイルしか扱えません。

最後に、これはわりと決めごとですが、現在の vctest ではコーデックに処理を投げる前にキャッシュメモリをフラッシュしようとします。この処理はかなり時間がかかるのですが、こんなことをやっていたら計測精度どころの話ではないため、CPU 使用率を出すときはキャッシュメモリのフラッシュは省略する必要があり、普通の計測とは比較できなくなります。普通の計測の方でも省略すればいい話ですけが、そうすると今度は今までの計測とは比較できなくなります。

なお、精度の低下を許容するという話であれば、そもそも vctest に計測機能を追加するまでもなく、適当なエンコードソフトを使ってタスクマネージャで CPU 使用率を目視すればそれで事足ります。低下する精度はそれぐらいだと思っています。

さてどうしましょうかね。

（思うところあったのでその３に続く）