今までの実行Profileを見ると、文字コードの変換にかなりの時間がかかっていることが分かる。
以前にも書いた通り今回の検証はWindowsXP上で行っているから、ファイル出力をする際にJavaの内部文字コードからShift_JISへの変換を行っている。その負荷が高いのだ。
sun.io.CharToByteDoubleByte.convert、sun.io.CharToByteMS932.convSingleByteといったあたりが文字コード変換に関係する処理だが、実行時最適化を行っていても、それらの処理の負荷は全体の半分以上を占めてしまっている。
しかしこれは、Javaが文字コードについてプラットフォーム独立であるために必須の処理でもあり、文字列入出力に常につきまとう問題である。
つまりここで一つの結論を出しても良さそうだ。
結論１）
文字列入出力について、Javaはその仕様上、変換処理が必須となる分、遅い
Ｃ言語の場合、それぞれのプラットフォームでサポートされている文字コードだけを扱えば通常事足りるので、わざわざ変換処理を行う必要はない。
もしも、ソースコードとプラットフォームとで文字コードが異なるのであれば、予め変換しておいてからバイナリ化しても良い。
もちろん、Ｃ言語でも異なる文字コードを変換するような処理ではJavaと事情はあまり変わらないと予想される。ただ、私にはその処理をどう書けば良いのか分からないのでここでの検証はできない。
ということで次は、文字コード変換処理有りのＣ言語の場合を検証する代わりに、文字コード変換の処理が無い場合のJavaのProfileを調べてみようと思う。
