今日から盆休みを取る社員が多く、会社が静かでいつもよりずっと集中できる。おかげで仕事はだいぶはかどった。
昨日の夜、上司からメールが来ていた。私が退社した後で上司がソフトウェアを動かしたらしい。その機体にインストールされているたのは少し古いバージョンで、最新版で修正済みのバグが残っている。起動しなくなったのもそのバグに関係がある。事前に動かすことを聞いていたらちゃんと最新版に入れ替えておいたのだが。
ともかく上司は別のバージョン（これも最新ではない）に入れ替えて動かしてみたらしい。で、「動かした感じでは動作速度が足りないから速度に関係する設定値に上限（下限）を設けるように」という指示がきた。
設定値の上限・下限に制限をかけるのはやぶさかではないけど、今さら速度が足りないとか言うのは勘弁してほしい…*1。
ともかくまずは設定値の制限を実装した。検出したハードウェアごとに制限する値の範囲をを変えないといけないのがめんどくさいが、実装自体は難しい物ではない。
これを保険に、処理そのものを高速化できないか少し丁寧に調べてみた。ソフトウェアの高速化に限らないが、何らかの改良をする場合は何よりも改良の程度を計測する手段を用意しなければならない。今回は処理時間を計測するために、パフォーマンスタイマーを使って正確に時間を測定する関数を用意した。（正確に言うと、前に作ってあったものを改良した）
その関数で現在の処理速度を計測しておいて、以降の高速化の程度を評価する。
まずは無駄なコードの削除。マルチスレッドに不慣れな頃にむやみに使っていたクリティカルセクションを削除した。これは大した効果はない。他には明らかに無駄なコードは無かったので、次に手を入れる場所を絞るためにボトルネックを探す。
ちまちまと処理時間を計測り、時間のかかる処理を探していく。その結果、時間が掛かっているのは描画処理、特にポリラインを描画する部分であることが分かった。まずはここを重点的に調べていく。この部分をさらに詳しく時間計測してゆき、特に時間のかかっている関数を特定する。結果的には、画面を更新する際に背景色を塗りつぶす処理が時間を食っていることが分かった。後は処理時間を計りながらこの部分のコードを弄っていく。
もちろんどうやっても高速化できない場合もあるが、幸い今回はかなりの高速化に成功した。これまであらかじめ背景色で塗りつぶしてあったバッファ画面を丸ごとコピーすることで背景色での塗りつぶしを実現していたが、背景色のポリラインで前回のポリラインを上書きする方式に変えることで、処理速度を約1.5倍に向上することができた。
これで処理速度の問題は相当改善されたはず。念のため設定値の制限はそのままにしてあるが、制限なしでも大抵は大丈夫だと思う。
最大の問題が大幅に前進したので、前から気になっていた問題も突っ込んで調べてみた。こちらはスレッドが正しく終了しないせいでソフトウェア終了後にプロセスが残るというバグ。開発環境でスレッドをモニタしながら終了処理を修正していく。このバグも開発環境上では解決した。実機でも試してみたが、おそらく解決したと思われる*2。
