Yuki>最適化

最適化

Yukiの最適化には大きく分けて以下の二種類がある。

  • ソースコード最適化 (通常最適化)
  • リアルタイム最適化 (高度最適化)


ソースコード最適化 (通常最適化)

論理的に等価であるものを、より(速度的に・資源的に)効率の良い状態へと最適化、及び無駄なコードを除去する。 インライン展開した方が良いものに関してはインライン展開を実施する。

ただし、多くの最適化はコンパイラの方で勝手にやってくれるので、それらに関しては最適化は実施しない(無駄手間+余計に時間が掛かるだけなので)。 Yukiの最適化では、コンパイラではやってくれないような、より高度な最適化を実施する。

例えば、ソースコード解析ツールの指摘は、その多くが機械的に修正できる。
Javaの文字列連結等が有名な例で、

String s;
for(int i=0; i<1000; i++)
   s += hogeStringArray[i];

Stringクラスへの+=では、毎回StringBufferがnewされるのでメモリ的にも速度的にも非効率である。 このコードは以下へと最適化出来る。

StringBuffer sb;
for(int i=0; i<1000; i++)
   sb.append(hogeStringArray[i]);
String s = sb.toString();

このような、コンパイルでは実施されないようなレベルで且つ機械的に変換可能(等価である)ものの最適化を行う。


リアルタイム最適化 (高度最適化)

Yukiのデータ構造を、バックグラウンドでリアルタイムに(別スレッドで)解析し、最適化可能な箇所を見つけた場合に、これを最適化するかどうかユーザに尋ね、承認された場合にそれを最適化する機能である。この最適化は以下の二つに分けられる。

不完全等価最適化

ソースコード解析ツールの指摘の中には、最適化する事により挙動が若干変わってしまう可能性がある(等価にならない)ものや、効率がトレードオフとなるもの(速度は上がるが、メモリ使用量も増える、逆にメモリ使用量は下がるが速度も落ちる、等)がある。
これをソースコード最適化の中で機械的に修正してしまうと予期せぬバグを埋め込んだり、ユーザの意図と異なる動作になってしまう場合がある。 よってこれらは機械的に修正せずに、ユーザに問い合わせ、承認された場合のみに最適化するようにする。

なお、ユーザへの問い合わせでは、その修正によりどのようなバグを埋め込む可能性があるか、等の情報も提示する。(親切!

最適化提案 (超高度最適化)

現存するソースコード解析ツールでは指摘されないような、超高度な最適化を実施する。
具体的には、そのソースコードを見て、書き手が実際にどう言った処理を行いたいのか予想し、その予想結果から最適解なコードを計算し、 その計算結果のコードが現存のコードと異なる場合には、ユーザにその最適解と予想されるコードを使用するかどうか尋ねる、と言うものである。

この処理には非常に時間が掛かることが予測されるため、恐らくコードを記述した瞬間にその提案がなされる事はまずない。
CPU処理時間が空いている時にバックグラウンドで計算し、計算結果が出た時点でユーザに提案するようにする。
(毎回ユーザに尋ねられるのはうざったいので、とある画面を見ると計算結果の一覧が表示され、それを適応するかしないかを選択させるようにしてもいいかもしれない)