本稿はjavaとcのパフォーマンス分析から始まったシリーズ「スタバに行ってコーヒーを飲もう」の

最終稿です。きっと（笑）

第１稿目では仮想メソッドがインラインになることによるパフォーマンスアップ。

第２稿目ではコンパイル単位が関数だという分析を行っていました。

[0回]

だっておかしいやん。

インラインしちゃったら再利用できないよ。

そんな声が聞こえてきそうな第３稿目。

インラインされた関数はどうなる。どうする。これからの政治。（おぃ

class B extends bench { int get() { return 1;} }
class C extends bench { int get() { return 2;} }
class D extends bench { int get() { return 3;} }
 
abstract public class bench {
  abstract int get();
  public static void main(String args[]) {
    bench f[] = {new B(), new C(), new D()};
    int sum=0;
    for(int i=0;i<args.length;i++)
    {
      sum += bench.test(f[Integer.parseInt(args[i])]);
    }
    System.out.println(sum);
  }
 
  static int test(bench f) 
  {
    int sum=0;
    for( int i=0; i<1000000000; i++ )
    {
      sum+=f.get();
    }
    return sum;
  }
 
}

ケース１：java bench 0 0 → 0.1 s
ケース２：java bench 0 1 → 1.5 s

はい、見事にインラインされた関数はリコンパイル対象になりますね。。
引数のクラスの型に基づいて別関数としてコンパイルされるのかな？
これで第１稿と第２稿で矛盾は発生しなくなりますね♪

そしてさらにパラメータを変えると

ケース３：java bench 0 1 0 → 1.5 s
ケース４：java bench 0 1 1 → 1.5 s

３回目の呼び出し時には前回呼び出した関数が再利用されていることが
分かります。。

これって・・javaの起動が重たい所以な気が。。

なにはともあれ、Cより速いこともありえることは確か。
その全貌を掴むのは意外に難しいみたいですね。

今回見つけたjavaがCより速くなるケース。

「暗黙のジェネリック」

と名づけましょう(笑)

NAME:

MAIL:

URL:

COLOR:
Black LimeGreen SeaGreen Teal FireBrick Tomato IndianRed BurlyWood SlateGray DarkSlateBlue LightPink DeepPink DarkOrange Gold DimGray Silver
SUBJECT:

COMMENT:


PASS:

トラックバックURL