JMH로 자바 코드 마이크로벤치마킹

🔔 이 글은 원래 제 사이트MihaiBojin.com에 올라온 글입니다. 🔔


일반적인 모범 사례로서 코드를 벤치마킹하는 것이 좋습니다.

JMH 또는 Java Microbenchmark Harness는 JVM 언어의 성능을 분석하는 데 사용할 수 있는 도구입니다.

Props 라이브러리의 성능을 프로파일링하고 싶었기 때문에 JMH를 코드베이스에 통합했습니다.

다음은 JMH Gradle 플러그인을 Java 코드베이스에 통합하는 방법에 대한 간단한 단계별 자습서입니다.

Gradle 구성

First, add the JMH Gradle plugin build.gradle.kts 파일:

plugins {
    id("me.champeau.jmh").version("0.6.6")
}


이렇게 하면 Gradle 프로젝트에 몇 가지 작업이 추가됩니다.
  • gradle jmh : 모든 벤치마크 실행
  • gradle jmhJar : 다른 시스템에서 실행할 수 있는 이식 가능한 JAR을 생성합니다
  • .

    두 번째 대상은 개발자 랩톱이 아닌 전용 컴퓨터에서 벤치마크를 실행하는 데 도움이 되며 결과적으로 예측 가능하고 비교 가능하며 재현 가능한 결과를 얻을 수 있습니다.

    JMH 벤치마크 작성

    The plugin expects all the benchmark code to exist in src/jmh/java and src/jmh/resources . This avoids having to create a separate project and importing all the code while at the same time avoiding shipping the benchmark code with the main library in src/main/java .

    Let's create the first benchmark. Save this file as src/jmh/java/Benchmark.java in your module.

    @Fork(value = 1, warmups = 1)
    @Warmup(iterations = 1)
    @Measurement(iterations = 1)
    @OutputTimeUnit(TimeUnit.SECONDS)
    public class Benchmark {
      @Benchmark
      public static void oneBenchmark() {
        // do something
      }
    }
    

    The code above is just scaffolding. Let's look at each annotation.

    @Fork: configures how many times the current benchmark is forked. If value=0 , the benchmark will be run in the same JVM. The warmups parameter defines how many times the benchmark is forked (but the results discarded).

    The main benefit of warming up is to load all classes and cache them. Unfortunately, since the JVM uses lazy loading and Just In Time compiling, the first iteration of our benchmark would incur the cost of all these actions and skew the results.

    @Warmup determines how many warmups are performed and discarded per fork.

    @Measurement allows us to specify how many iterations to execute per benchmark.

    And finally, @OutputTimeUnit allows us to specify the unit reported in the results.

    There are more annotations and parameters, but I won't get into the weeds of it just yet.

    "소비" 결과

    There is a small caveat when writing benchmarking code in that the JVM is smart enough to optimize code that is not actually used.

    For example, in the following code, the result of tested.get() is never used (consumed) so the running JVM may decide to simply skip the call altogether, making the benchmark invalid.

    public class Benchmark {
      @Benchmark
      public static void oneBenchmark() {
        // assume an object under test
        tested.get();
      }
    }
    

    JMH introduces the concept of a Blackhole . The code above can be rewritten, ensuring the results are always used and the code being benchmarked is executed:

    public class Benchmark {
      @Benchmark
      public static void oneBenchmark(Blackhole blackhole) {f
        // the code under test is always executed
        blackhole.consume(tested.get());
      }
    }
    

    You can now run all the benchmarks with the gradle jmh command.

    Et voila! A super simple intro to JMH in a Gradle project!

    추가 읽기

    For additional details, see:

  • a slightly more in-depth JMH tutorial
  • JVM warmup에 대한 설명
  • JMH Gradle plugin에 대한 추가 구성 옵션
  • JMH project

  • 다음 시간까지!


    이 기사가 마음에 들었고 더 읽고 싶다면 please subscribe to my newsletter ; 몇 주에 한 번씩 보내드립니다!

    좋은 웹페이지 즐겨찾기