最近、KNOPPIXのカスタマイズを行っている。KNOPPIX 6.0では、起動シーケンスが大幅に改善されており、少ない待ち時間で起動することができる。
このKNOPPIXでは、日本ではLCATという起動を早くするためのcloopモジュールなどの工夫が存在する。そのモジュールよりも、プレゼン資料においてKNOPPIXの起動時にどこに時間がかかっているのかを分析している資料の方が興味深い。
この資料によると、横軸に時間軸でCPUの処理時間などが記述されているが、CPUが使われていない時間帯が存在する。おそらくディスクアクセスが大きくなっていたりハードウェアの認識を行っていたりするのだろうか。KNOPPIX 6.0ではudev部分が並列化されており、そのバックグラウンドでネットワークなどの起動を行っていたりする。
また別の話だが、adobe reader(acrobat reader)をダウンロードする際にDLMというプラグインをインストールさせられ、getPlusのダウンロードマネージャーによってadobe readerをインストールするという流れになっている。このマネージャーでは、ダウンロードと圧縮解凍の処理を同時に行っており、ダウンロード時に余っているCPU資源を有効活用できるようになっている。
Windowsでは、このようなダウンロード中のファイルに関してファイルロックがかかってしまうため、別のプロセス（例えばブラウザ）が書き込みを行っているものに対しての読み込みは難しいのかもしれないが、1つのプロセスで両方行うことが出来れば時間短縮が行えるというアイディアだ。
最近のソフトウェアでも直列的（シリアル）な作業を行わせようとするケースは多く、待ち時間中に出来ることをしていない。例えばストリーミングもダウンロードが終わる前に見られるようにするアイディアだ。
このような事象が発生しているかどうかを分析するには、簡易的にはディスクアクセス（もしくはネットワークアクセス）とCPU使用率のどちらがボトルネックになっているのかについて注意深く知ることで、できそうだ。
例えばKNOPPIXの作成時を例にする。KNOPPIXの作成にはKNOPPIXに入れるソフトウェア群の圧縮を行う必要があり、この圧縮作業に通常の設定では13分程度の時間がかかる。テストを行おうとするたびに13分程度の時間を待つ必要があり、辟易していた。
この圧縮作業について調べてみたところ、最高圧縮(9)のgzipで行うようになっていた。そこで最低圧縮(1)のgzipで圧縮を行うようにしたところ、2〜3分でテストできる状態を作成できるようになった。当初は無圧縮(0)で検討したが完成後のファイル容量が2,3倍程度になってしまい、またCPUをそれほど使わずにディスクアクセスがボトルネックになっているようだった。最低圧縮のgzipでは最高圧縮に比べて1割程度の増分で済み、CPUを80~90%ほど消費してディスクアクセスもそれほどボトルネックにはならなかったので早くなったのだろうと推測している。
このような例が他にはないか、探してみるのも面白そうだ。