🙎🏿 🥢 👩🏻‍⚖️ Java 8式のパフォーマンス 🕡 🖕🏼 🧓🏻

Java 8のリリースに伴い、言語はラムダ式をサポートし始めましたが、2013年半ばに4年が経過し、多くの更新がリリースされ、Java 9が間もなく登場します（おそらく、一定の遅延）ので、時間の合流点で、Javaの新しいツールと世界のような古いツールのパフォーマンスを要約して評価し、定量的な評価を行いたいと思います。

socmetr.lambda.comparison

他の事柄がラムダ式の長所と短所について説明したように、パフォーマンス評価はすでに数回行われています。

最初のインクルード：

-コードの簡素化と削減

-機能的なスタイルを実装する可能性

-並列計算の可能性

第二に ：

-生産性の低下

-デバッグの難易度

ユーザーdmmm （ https://habrahabr.ru/post/146718/ ）によって、5年前に優れた手法とテストが説明および使用され、それらが基礎として採用されました。

要するに、テスト自体がLambdaJプロジェクトで提供された場合。 dmmmはGuavaプロジェクトのテストを追加し、habr-community（2012）との議論の後に調整しました。

私（つまり、 blutovi ）はすべてのラムダテストを書き直しました（テストはJavaのアルファバージョンで実行され、現在の状態ではコードをコンパイルできないため）。また、Java Mission Controlを使用してメモリステータスを分析し、テストごとにjfrファイルを添付しました結果で。（JVM診断および監視ツールであるJava Mission Controlは、SunのHotSpotとOracleのJRockitの2つのJVMのアイデアを組み合わせた結果、java 7 update 40から利用可能になりました）。

どのようにテストされましたか？

junitテスト自体は、3つのフェーズで構成されます：収集の初期化、アイドル実行、統計収集による実行（時間計算は最後の段階でのみ実行され、メモリ操作の分析はサイクル全体で実行されます）。

時間測定は次のように実行されます。

z

${z}$ 経時的な反復

Y

${Y}$ 、テストアルゴリズムの順次呼び出しが発生します。有効期限が切れると、アルゴリズム実行の算術平均時間が決定されます

b a r Y_{z}

$\ bar {Y} _ {z}$ ：

b a r Y^{z} = f r a c 1 n_{z} s u m_{i = 0}^{n_{z}} Y_{i}^{^{'}}

$\ bar {Y} ^ {z} = \ frac {1} {{n} _ {z}} \ sum_ {i = 0} ^ {{n} _ {z}} {Y} ^ {'} _ {i}$

合計実行時間を分割することにより

Y^{^{'}}

${Y} ^ {'}$ 回数で

n

${n}$ 彼は何とかして成し遂げました。に基づいて

z

${z}$ 繰り返し、アルゴリズムの合計平均実行時間を見つけます：

b a r Y = f r a c 1 z s u m_{i = 0}^{z} b a r Y_{i}^{z}

$\ bar {Y} = \ frac {1} {z} \ sum_ {i = 0} ^ {z} \ bar {Y} ^ {z} _ {i}$

大きさで

z

${z}$ （反復回数）および

Y

${Y}$ （テストアルゴリズムが呼び出される時間）は、クラスch.lambdaj.demo.AbstractMeasurementTestの定数の値を変更することにより影響を受ける可能性があります。

public static final int WARMUP_ITERATIONS_COUNT = 10; public static final int ITERATIONS_COUNT = 10; public static final int ITERATION_DURATION_MSEC = 1000;

テストは、Java Mission Controlの操作用にアクティブ化されたパラメーターを使用して実行され、診断ファイルの自動生成が許可されました。

結果

絶対的に （値が小さいほど良い ）

	のために		繰り返す		グアバ		jdk8 lambda
	時間、ns	ヒープMb	時間、ns	ヒープMb	時間、ns	ヒープMb	時間、ns	ヒープMb
車の元のコストを抽出する	220.4	313	200.6	324	188.1	302	266.2	333
50k以上で購入した最年少の年齢	6367	260	4245	271	6367	260	6157	278
最年少の人の買い物を見つける	6036	270	6411.4	259	6206	260	6235	288
最も購入した車を見つける	2356	167	2423	171	5882	193	2971	190
最も高価なセールを見つける	49	71	58.1	66	431.6	297	196.1	82
買い手と売り手によるグループ販売	12144	250	12053	254	8259	206	18447	242
ブランド別のインデックス車	263.3	289	275.0	297	2828	226	307.5	278
すべてのブランドを印刷	473.2	355	455.3	365	540.3	281	514.2	337
フェラーリのすべての販売を選択	199.3	66	265.1	53	210.4	111	200.2	65
コストで売上を並べ替える	1075	74	1075	74	1069	72	1566	124
両方が男性の場合の合計費用	67.0	63	72.9	58	215.9	88	413.7	114

相対的な用語で （100％がベースで、値が低いほど良い ）

	のために		繰り返す		グアバ		jdk8 lambda
	時間	ヒープ	時間	ヒープ	時間	ヒープ	時間	ヒープ
車の元のコストを抽出する	117％	104％	107％	107％	100％	100％	142％	110％
50k以上で購入した最年少の年齢	150％	100％	100％	104％	150％	100％	145％	107％
最年少の人の買い物を見つける	100％	104％	106％	100％	103％	100％	103％	111％
最も購入した車を見つける	100％	100％	103％	102％	250％	116％	126％	114％
最も高価なセールを見つける	100％	108％	119％	100％	881％	450％	400％	124％
買い手と売り手によるグループ販売	147％	121％	146％	123％	100％	100％	223％	117％
ブランド別のインデックス車	100％	128％	104％	131％	1074％	100％	117％	123％
すべてのブランドを印刷	104％	126％	100％	130％	119％	100％	113％	120％
フェラーリのすべての販売を選択	100％	125％	133％	100％	106％	209％	100％	123％
コストで売上を並べ替える	101％	103％	101％	103％	100％	100％	147％	172％
両方が男性の場合の合計費用	100％	109％	109％	100％	322％	152％	617％	197％

結論

要約すると、ラムダ式を使用してさまざまな方法で同じことが実装できることに注意してください：ただし、パフォーマンスの最適なオプションであっても、単純なソリューションよりも劣り、最適なオプションではなく、パフォーマンスに大きな影響を与える可能性があります。

したがって、反復アプローチにより、実行速度に焦点を当てることが可能になり、 グアバでは、 使用されるメモリの量に焦点を当てて、それを最小限に抑えることができます。 ラムダ式を使用すると、審美的な喜びだけが得られるようです（驚いたことに）。

テストを変更および改善する方法に関する提案を歓迎します。

Java 8式のパフォーマンス

どのようにテストされましたか？

結果

結論

参照資料

More articles: