実行速度最適化の開発メモ                                            2006.05.14
───────────────────────────────────────

  Eclipse は起動時に 4,000 個以上のクラスをロードし、Pleiades はそれらの
  クラスに対して 150,000 個以上のメソッド呼び出し（※1）を Javassist で検査
  しますが、これに非常に時間がかかります（※2）。

  Pleiades は Eclipse 起動オプションの -clean を使用して、今のところ以下のような
  単純な最適化を行います。


 【-clean 指定ありの動作】

    ・全クラス・メソッド呼び出し検査 → ウィービング対象外リストとして保存
    ・翻訳時にニーモニックの処理     → 圧縮翻訳キャッシュとして保存
    ・正規表現による翻訳             → 圧縮翻訳キャッシュとして保存
    ・翻訳できない項目               → 圧縮翻訳キャッシュとして保存

 【-clean 指定なしの動作】

    ・ウィービング対象外リストにあるクラスはウィービング除外
    ・圧縮翻訳キャッシュを元に翻訳


  Eclipse 起動時に Pleiades の処理に要する時間
 ┌────┬───────────┬───────────┬────┐
 │ -clean │ AOP（約 4,000クラス）│ 翻訳（約 45,000 個） │  合計  │
 ├────┼───────────┼───────────┼────┤
 │  なし  │        0.78秒        │       0.01秒         │ 0.79秒 │
 │  あり  │        4.89秒        │       1.13秒         │ 6.02秒 │
 └────┴───────────┴───────────┴────┘

 （※1）メソッドの実行部分だけをウィービングすれば、高速に処理できるのですが、
        JDK のライセンスに抵触する可能性があるため、呼び出し部分をウィービング
        しています。Eclipse のコードについては実行部分をウィービングしています。

 （※2）Javassist が BCEL や cglib などの他のバイトコード・ライブラリーと比較
        して遅いわけではありません。ASM と同程度であり、数が多いため時間が
        かかっているだけで十分高速です。また実際に処理が必要なジョイントポイント
        はごくわずかで、-clean 指定なしの場合、起動時間に対してウィービングに
        要している時間は数 % です。


  Eclipse 自体の高速化を検証した結果

    ・初回起動時に Eclipse がロードしたバイトコードとウィービング後のバイトコー
      ドをシリアライズして圧縮保管。

        → シリアライズ自体が遅すぎで×。

    ・初回起動時に全クラスのバイトコードを直接 1 つの圧縮ファイルに保管。
      Eclipse のクラスローダーをウィービングし、独自クラスローダーに改造。
      Java 自体に備わるセキュリティチェック機構も解除（いいのか？）。

        → ノーマル Eclipse をはるかに上回り、怖いくらいの速度で起動。
           と思ったらエラー連発。クラスローダー改が Eclipse の動作に必要な
           OSGI フレームワークの処理まですっとばしていた模様。
           複雑になりすぎたのと、Eclpse の OSGI 実装を追いきれず挫折。

    ウィービングやアドバイスの処理をいくら高速化してもノーマルの Eclipse より
    遅くなってしまうため、Eclipse 自体を改造し、ノーマル Eclipse を超える速度を
    実現しようともがいてみましたが、だめでした。。。
    とりあえず、OSGI というかプラグインの仕組みに関する部分が、起動時間のうち
    かなりの部分を占めているようです。
