1

コードのプロファイリングを行ったところ、 を実装するクラスがComparable<T>8 倍の CPU 時間を消費していることがわかりました。

compareTo(Object)

よりも

compareTo(T)

スローダウンは、このメソッドの仮想テーブル ルックアップが原因であると想定しています。


関数の静的呼び出しを強制する方法はありますか? (非仮想 C++ メソッドと同様)

このオブジェクトで Comparable<T>使用するため、インターフェイスを引き続き使用したいので、このコードを書き直したくありません。編集:いいえ、私はcompareTo(Object) を実装しませんでした-これは自動的に生成され、プロファイラーによって報告されましたTreeSet


4

4 に答える 4

4

あなたが見てcompareTo(Object)いる理由はType Erasureによるものです。これは、実行時に値を比較するために型情報が不要になったことを意味します。ほとんどの場合、速度低下の理由は 1) 多数の要素を持つ非常に大きな TreeSet です 2) - より可能性が高いのは、compareTo メソッドが高価な処理を行っていることです。非常に頻繁に呼び出されるため (通常は n*ln(n) 回)、効率的に実装する必要があります。

于 2009-03-10T16:51:13.813 に答える
2

いいえ、この場合、静的呼び出しを強制することはできません。

invokespecialインスタンス メソッドは、命令によって「非仮想的に」呼び出すことができます。この命令は、コンストラクターやプライベート メソッドのように、コンパイル時にターゲットがわかっている場合に使用されます。それ以外の場合は、ターゲット メソッドが であっても、finalまたはinvokevirtual命令invokeinterfaceが使用されます。

于 2009-03-10T17:04:42.987 に答える
1

Java は実行時にジェネリック型を保持しないため、両方が同じように動作することが理想的です。おそらく、問題を引き起こしている何か他のものがあります。

于 2009-03-10T16:42:20.183 に答える
0

スローダウンは、このメソッドの仮想テーブル ルックアップが原因であると想定しています。

これが本当かどうかを推測する必要はありません。数回一時停止するだけで、実際にそれをキャッチできます。ライブラリ ルーチンへの呼び出しを含め、コール スタック全体を表示します。

私の推測 (これは間違っている可能性があります) は、9 ヤードの OLE スタイルの呼び出しフーホーを通過しているということです。

于 2009-03-10T17:10:17.480 に答える