動機はともあれ、なにかしら急に思い立って、stViewerの動作速度改善作業をやってみた。
ソースの修正ってっても、動作時にクリティカルになってる部分、つまり動作に時間がかかっているところの修正を行いました。もっと具体的にいうなら、ファイルからの読み込み時と検索時ですけどね。もともと、これまでよりも速度を改善するためのロジックをぼんやりイメージしていたので、それを実際にソースに落としてみたというところです。
そしてその結果、検索速度はこれまでの20倍以上(当社比)となり大成功。しかし、ファイル読み込みは逆に遅く(当社比)なってしまいました。ううーーーん、これは意外。プログラマ的直感で絶対に早くなると思ってたのに。。
具体的には以下のような感じです。IOから読み込んだのがbyte[] bufに入っているとして、String[] bodyへ1行ごとにぶった切った文字列を入れていくとします。従来が
String tmp = new String(buf);
for(int i=0; i<100; i++){
body[i] = tmp.substring( i*20, (i+1)*20);
}という感じだったのを、for(int i=0; i<100; i++){
body[i] = new String( buf, i*20, 20);
}としてみた、という感じです。つまり、従来は読み込んだbyte[]をいきなりでかいStringに変換してしまいそれからsubstringでちまちま切っていたのを、今回byte[]のまま切れ目を探す処理をしそして1行ごとにnew Stringしてみた、ということです。
これまではsubstringを実行しまくっているせいで無駄なStringのインスタンスを作っていた、その分が省けて実行速度も改善するだろう、と思いこんでいたわけです。ところが、JavaVMのString周りのインスタンス生成におけるメモリ管理がうまいんだろうか、逆に遅くなってしまいました。動作状況から察するに、どうもnew Stringを呼ぶ回数が増えた分ネックになってしまったという感じです。参考までに、公開しているstViewerのソースコードのアーカイブには、「view.java.bak」としてその改変したやつを添付しておきます。
まぁそんなわけで、思い立って行動した時間のうち、ファイル読み込み関連のソース修正(+そのパフォーマンス測定)にかかった時間3時間ちょいが無駄になりました。誰か利子つけて返してください。おながいしまつ。
