Javaコードの速度を正しく測定する（JMHを使用）

こんにちは、Habr！

これは、JVM言語（java、kotlin、scalaなど）でパフォーマンステストを行う方法についての入門記事です。 特定のアルゴリズムの使用によるパフォーマンスの変化を数値で示す必要がある場合に役立ちます。

すべての例は、kotlinとgradleビルドシステム用です。 プロジェクトのソースコードはgithubで入手できます 。

準備する

Jmh

まず、測定の主要部分であるJMHの使用について説明します。 Java Microbenchmark Harnessは、小さな関数（つまり、GCを一時停止するとランタイムが数倍増加するもの）のパフォーマンスをテストするためのライブラリのセットです。

テストを実行する前に、JMHは次の理由でコードを再コンパイルします。

1. 関数のランタイムを計算する際のエラーを減らすには、それをN回実行し、合計ランタイムを計算してからNで割る必要があります。
2. これを行うには、ループ形式で起動をラップし、必要なメソッドを呼び出す必要があります。 ただし、この場合、サイクル自体と測定された関数の呼び出しは、関数の動作時間に影響します。 したがって、ループの代わりに、実行時のリフレクションまたはメソッド生成なしで、関数呼び出しコードが直接挿入されます。

バイトコードの変更後、すべての必要なコンポーネントがすでに1つのjarファイルにパックされているため、 java -jar benchmarks.jar



の形式のコマンドでテストを開始できます。

JMH Gradleプラグイン

上記の説明からわかるように、コードのパフォーマンスをテストするには、クラスパスに必要なライブラリを追加して、JUnitスタイルでテストを実行するだけでは不十分です。 したがって、ビジネスを行い、ビルドスクリプトを記述する機能を理解していない場合、maven / gradleプラグインなしでは実行できません。 新しいプロジェクトの場合、gradleには利点があるため、選択してください。

JMHには、 gradleの半公式プラグインjmh-gradle-pluginがあります 。 プロジェクトに追加します。

 buildscript { repositories { mavenCentral() maven { url "https://plugins.gradle.org/m2/" } } dependencies { classpath "me.champeau.gradle:jmh-gradle-plugin:$jmh_gradle_plugin_version" } } apply plugin: "me.champeau.gradle.jmh"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プラグインは自動的に新しいソースセットを作成します（これは「コンパイルして一緒に実行する必要があるファイルとリソースのセットです」。 jmhソースセットは自動的にメインを参照します。つまり、作業の短いアルゴリズムを取得します。

1. いつもと同じ場所で、標準のメインソースセットで変更するコードを記述します。
2. 別のソースセットでテストを調整およびウォームアップするコードを記述します。 上書きされるのは彼のバイトコードです。ここでは、プラグインが必要な依存関係を追加し、その中に注釈の定義などがあります。

次のディレクトリ階層を取得します。

• src
  
  
  • jmh / kotlin / <パッケージjava名> / <テストを実行するコード（およびJMH属性の注釈付き）>
  • main / kotlin / <パッケージjava名> / <テスト用コード>

または、IntelliJ Ideaでどのように見えるか：

その結果、プロジェクトをセットアップした後、 .\gradlew.bat jmh



（またはLinux、Mac、BSDの場合は.\gradlew jmh



を呼び出すだけでテストを実行できます.\gradlew.bat jmh

Windowsのプラグインには、いくつかの興味深い機能があります。

• JMHはプロセスのfork javaを使用します。 Windowsの場合、これを簡単に行うことはできず、新しいプロセスは同じクラスパスで開始されます。 また、jarファイルのリスト全体がコマンドライン経由で送信されますが、サイズは制限されています。 その結果、GRADLE_USER_HOME（gradleキャッシュを含むフォルダー）がファイル構造の深さにある場合、forkのjarファイルのリストは非常に大きくなり、Windowsはこのような膨大な数のコマンドライン引数でプロセスを開始することを拒否します。 したがって、 JMHがフォークを拒否した場合、Gradleキャッシュを短い名前のフォルダーに移動するだけです。 環境変数GRADLE_USER_HOMEにc：\ gradleのようなものを書きます。
• 以前のJMHプロセスがファイルをロックする場合があります（バイトコードの書き換えがこれを行う可能性があります）。 その結果、ベンチマーク用のファイルが書き込みのために誰かによって開かれたため、再コンパイルが機能しない場合があります。 この問題を修正するには、デーモンgradleプロセス（コンパイラを高速化するために既に実行されている）を停止する必要があります。 .\gradlew.bat --stop
  
  
  
  
• 実験の純度を高めるには、テスト用のインクリメンタルアセンブリを中止することをお勧めします。 ここから、テストする前に必ず電話してください.\gradlew.bat clean
  
  
  
  

テスト中

例として、以前に私を苦しめた質問（以前kotlinの議論で尋ねられました）を取り上げます-インライン構造がuseコンストラクトで使用されるのはなぜですか？

 try (BufferedReader reader = Files.newBufferedReader(file, charset)) { //  try     /*  reader'*/ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 Files.newBufferedReader(file, charset)).use { reader -> /*  reader'*/ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、2つの方法を作成する必要があります。

1. 最初のものはuseを使用するだけで、kotlinライブラリに含まれています
2. 2番目は同じメソッドを使用しますが、インラインは使用しません。 その結果、ヒープの呼び出しごとに、ラムダのパラメーターを持つオブジェクトが作成されます。

さまざまな機能を実行するJMH属性を持つコード：

 @BenchmarkMode(Mode.All) //     @Warmup(iterations = 10) //       @Measurement(iterations = 100, batchSize = 10) //   ,           open class CompareInlineUseVsLambdaUse { @Benchmark fun inlineUse(blackhole: Blackhole) { NoopAutoCloseable(blackhole).use { blackhole.consume(1) } } @Benchmark fun lambdaUse(blackhole: Blackhole) { NoopAutoCloseable(blackhole).useNoInline { blackhole.consume(1) } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デッドコード除去

JavaコンパイラとJITは非常に賢く、コンパイル時と実行時の両方で多くの最適化が行われています。 たとえば、次のメソッドは1行に折りたたむことができます（kotlinとjavaの両方）：

 fun sum() : Unit { val a = 1 val b = 2 a + b; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最後に、メソッドをテストします。

 fun sum() : Unit { 3; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、原則として必要ないため、コンパイラ（バイトコード+ JIT）は最終的にメソッドを完全に破棄するため、結果はどのような方法でも使用されません。

これを回避するために、JMHには特別な「ブラックホール」クラスがあります-ブラックホール。 一方では何もせず、もう一方ではJITに結果のブランチをスローさせないメソッドがあります。

そして、javacがコンパイルプロセス中にaとbを追加しようとしないように、値が格納される状態オブジェクトを定義する必要があります。 その結果、テスト自体では、すでに準備されたオブジェクトを使用します（つまり、作成に時間を浪費せず、コンパイラーが最適化を適用することを許可しません）。

そのため、関数を適切にテストするには、次の形式で記述する必要があります。

 fun sum(blackhole: Blackhole) : Unit { val a = state.a //      a val b = state.b val result = a + b; blackhole.consume(result) // JIT    ,    - -  }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、ある状態からaとbを取得しました。これにより、コンパイラーが式をすぐに計算できなくなります。 そして、結果をブラックホールに送信しました。これにより、JITが関数の最後の部分を捨てることができなくなります。

私の機能に戻る：

1. ほとんどの場合、closeメソッドを呼び出すときにその前にオブジェクトを作成したため、テスト自体でcloseメソッドを呼び出すためのオブジェクトを作成します。
2. メソッド内で、ヒープにラムダを作成するためにブラックホールから関数を呼び出す必要があります（そして、JITが潜在的に不要なコードをスローするのを防ぎます）。

試験結果

./gradle jmh



を実行してから2時間待つと、mac miniで次の結果が得られました。

 # Run complete. Total time: 01:51:54 Benchmark Mode Cnt Score Error Units CompareInlineUseVsLambdaUse.inlineUse thrpt 1000 11689940,039 ± 21367,847 ops/s CompareInlineUseVsLambdaUse.lambdaUse thrpt 1000 11561748,220 ± 44580,699 ops/s CompareInlineUseVsLambdaUse.inlineUse avgt 1000 ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.lambdaUse avgt 1000 ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse sample 21976631 ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.00 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.50 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.90 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.95 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.99 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.999 sample ≈ 10⁻⁵ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p0.9999 sample ≈ 10⁻⁵ s/op CompareInlineUseVsLambdaUse.inlineUse:inlineUse·p1.00 sample 0,005 s/op CompareInlineUseVsLambdaUse.lambdaUse sample 21772966 ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.00 sample ≈ 10⁻⁸ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.50 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.90 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.95 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.99 sample ≈ 10⁻⁷ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.999 sample ≈ 10⁻⁵ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p0.9999 sample ≈ 10⁻⁵ s/op CompareInlineUseVsLambdaUse.lambdaUse:lambdaUse·p1.00 sample 0,010 s/op CompareInlineUseVsLambdaUse.inlineUse ss 1000 ≈ 10⁻⁵ s/op CompareInlineUseVsLambdaUse.lambdaUse ss 1000 ≈ 10⁻⁵ s/op Benchmark result is saved to /Users/imanushin/git/use-performance-test/src/build/reports/jmh/results.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、テーブルを短くする場合：

 Benchmark Mode Cnt Score Error Units inlineUse thrpt 1000 11689940,039 ± 21367,847 ops/s lambdaUse thrpt 1000 11561748,220 ± 44580,699 ops/s inlineUse avgt 1000 ≈ 10⁻⁷ s/op lambdaUse avgt 1000 ≈ 10⁻⁷ s/op inlineUse sample 21976631 ≈ 10⁻⁷ s/op lambdaUse sample 21772966 ≈ 10⁻⁷ s/op inlineUse ss 1000 ≈ 10⁻⁵ s/op lambdaUse ss 1000 ≈ 10⁻⁵ s/op
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、2つの最も重要なメトリックがあります。

1. インライン方式は、1秒あたり11,6 * 10^6 ± 0,02 * 10^6
   
   
   
   操作の生産性を示しました。
2. Lambdaベースのメソッドは、1秒あたり11,5 * 10^6 ± 0,04 * 10^6
   
   
   
   操作のパフォーマンスを示しました。
3. 結果として、インライン方式はより高速で、速度がより安定します。 lambdaUseのエラーの増加は、おそらくメモリを使用したよりアクティブな作業に関連している可能性があります。
4. 私はそのフォーラムで間違っていました-kotlin標準ライブラリに現在のメソッド実装を残した方が良いです。

おわりに

ソフトウェアを開発するとき、パフォーマンスを比較する2つのかなり一般的な方法があります。

1. 実験関数のN回の反復によるサイクルの速度の測定。
2. 「2を乗算するよりもシフトを使用する方が速いと確信しています」、「プログラミングする限り、XMLシリアル化は常に最速でした」などの哲学的考慮事項など。

ただし、技術に精通した専門家なら誰でも知っているように、これらのオプションはどちらも誤った判断やアプリケーションブレーキなどにつながることがよくあります。この記事が良い高速ソフトウェアの作成に役立つことを願っています。

英訳はこちら 。