web-dev-qa-db-ja.com

Javaラムダは匿名クラスより20倍遅い

ここでJavaラムダのパフォーマンスについて多くの質問を見てきましたが、それらのほとんどは「ラムダはわずかに高速ですが、クロージャを使用すると遅くなります」または「ウォームアップ対実行時間異なる」などのことです。

しかし、私はここでかなり奇妙なことにぶつかりました。 このLeetCodeの問題 を考慮してください：

重複しない間隔のセットを指定して、新しい間隔を間隔に挿入します（必要に応じてマージします）。

間隔は、開始時刻に従って最初にソートされたと想定できます。

問題は強くタグ付けされたので、線形アプローチは彼らが望んでいるものではないと思いました。そこで、バイナリ検索と入力リストの変更を組み合わせる賢い方法を考え出すことにしました。現在、入力リストの変更に関する問題はあまり明確ではありません。署名がリストへの参照を返す必要がある場合でも、「挿入」と表示されますが、今のところは気にしないでください。完全なコードを次に示しますが、この質問に関係するのは最初の数行のみです。誰でも試せるように、残りはここに置いておきます。

public List<Interval> insert(List<Interval> intervals, Interval newInterval) {
    int start = Collections.binarySearch(intervals, newInterval,
                                         (i1, i2) -> Integer.compare(i1.start, i2.start));
    int skip = start >= 0 ? start : -start - 1;
    int end = Collections.binarySearch(intervals.subList(skip, intervals.size()),
                                       new Interval(newInterval.end, 0),
                                       (i1, i2) -> Integer.compare(i1.start, i2.start));
    if (end >= 0) {
        end += skip; // back to original indexes
    } else {
        end -= skip; // ditto
    }
    int newStart = newInterval.start;
    int headEnd;
    if (-start - 2 >= 0) {
        Interval prev = intervals.get(-start - 2);
        if (prev.end < newInterval.start) {
            // the new interval doesn't overlap the one before the insertion point
            headEnd = -start - 1;
        } else {
            newStart = prev.start;
            headEnd = -start - 2;
        }
    } else if (start >= 0) {
        // merge the first interval
        headEnd = start;
    } else { // start == -1, insertion point = 0
        headEnd = 0;
    }
    int newEnd = newInterval.end;
    int tailStart;
    if (-end - 2 >= 0) {
        // merge the end with the previous interval
        newEnd = Math.max(newEnd, intervals.get(-end - 2).end);
        tailStart = -end - 1;
    } else if (end >= 0) {
        newEnd = intervals.get(end).end;
        tailStart = end + 1;
    } else { // end == -1, insertion point = 0
        tailStart = 0;
    }
    intervals.subList(headEnd, tailStart).clear();
    intervals.add(headEnd, new Interval(newStart, newEnd));
    return intervals;
}

これは正常に機能し、受け入れられましたが、実行時間は80ミリ秒でしたが、ほとんどのソリューションは4〜5ミリ秒、18〜19ミリ秒でした。私がそれらを調べたとき、それらはすべて線形で非常に原始的でした。 「ハード」とタグ付けされた問題から期待するものではありません。

しかし、ここで疑問が生じます：私のソリューションは最悪の場合でも線形です（なぜなら、追加/クリア操作は線形時間だからです）。なぜthatが遅いのですか？そして、私はこれをしました：

    Comparator<Interval> comparator = new Comparator<Interval>() {
        @Override
        public int compare(Interval i1, Interval i2) {
            return Integer.compare(i1.start, i2.start);
        }
    };
    int start = Collections.binarySearch(intervals, newInterval, comparator);
    int skip = start >= 0 ? start : -start - 1;
    int end = Collections.binarySearch(intervals.subList(skip, intervals.size()),
                                       new Interval(newInterval.end, 0),
                                       comparator);

80ミリ秒から4ミリ秒まで！何が起きてる？残念ながら、どのような種類のテストをLeetCodeが実行するのか、またはどの環境で実行するのかはわかりませんが、それでも20倍ではありませんか？

javaperformancelambdaanonymous-class
33
Sergei Tachenov

ラムダ式の最初の初期化オーバーヘッドが明らかに発生しています。コメントで既に述べたように、ラムダ式のクラスは、クラスパスからロードされるのではなく、実行時に生成されます。

ただし、生成されることは速度低下の原因ではありません。結局のところ、単純な構造を持つクラスを生成することは、外部ソースから同じバイトをロードするよりも高速です。また、内部クラスもロードする必要があります。ただし、アプリケーションでラムダ式を使用したことがない場合は、ラムダクラスを生成するためのフレームワークもロードする必要があります（Oracleの現在の実装では、ASMを内部で使用しています）。これは、ラムダ式自体ではなく、内部的に使用される多数のクラスのスローダウン、ロード、および初期化の実際の原因です。

これは簡単に確認できます。ラムダ式を使用する現在のコードでは、2つの同一の式(i1, i2) -> Integer.compare(i1.start, i2.start)。現在の実装はこれを認識しません（実際、コンパイラーもヒントを提供しません）。そのため、ここでも、異なるクラスを持つ2つのラムダインスタンスが生成されます。内部クラスのバリアントと同様に、コードをリファクタリングしてコンパレータを1つだけにすることができます。

final Comparator<? super Interval> comparator
  = (i1, i2) -> Integer.compare(i1.start, i2.start);
int start = Collections.binarySearch(intervals, newInterval, comparator);
int skip = start >= 0 ? start : -start - 1;
int end = Collections.binarySearch(intervals.subList(skip, intervals.size()),
                                   new Interval(newInterval.end, 0),
                                   comparator);

重要なのはラムダ式の数ではなく、フレームワークのクラスのロードと初期化のみであるため、パフォーマンスに大きな違いはありません。

次のような追加のラムダ式を挿入することで最大化することさえできます

final Comparator<? super Interval> comparator1
    = (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator2
    = (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator3
    = (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator4
    = (i1, i2) -> Integer.compare(i1.start, i2.start);
final Comparator<? super Interval> comparator5
    = (i1, i2) -> Integer.compare(i1.start, i2.start);

減速は見られません。これは、ここで注目しているランタイム全体の最初のラムダ式の最初のオーバーヘッドです。 Leetcode自体は、実行時間を測定するコードを入力する前にラムダ式を使用しないため、このオーバーヘッドが実行時間に追加されます。

「どのようにJavaラムダ関数をコンパイルしますか？」 および 「ラムダ式は、実行されるたびにヒープ上にオブジェクトを作成しますか？」

52
Holger