Performance Profiling

// build.gradle adds the two JMH dependencies:
//   org.openjdk.jmh:jmh-core:1.37
//   org.openjdk.jmh:jmh-generator-annprocess:1.37   (annotation processor)
// Then run:  ./gradlew jmh        (or  java -jar target/benchmarks.jar)

package com.myapp.bench;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;
import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.AverageTime)             // report average ns per call
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1)            // let the JIT compile hot code first
@Measurement(iterations = 10, time = 1)      // THEN take the timed measurements
@Fork(2)                                     // fresh JVMs so one run can't bias the next
@State(Scope.Thread)                         // each thread gets its own copy of fields
public class StringConcatBenchmark {

    @Param({"10", "100", "1000"})            // run every benchmark at each size
    public int n;

    // The number 42 is a CONSTANT, so without a Blackhole the JIT would
    // delete this method entirely ("dead-code elimination") and you'd be
    // timing nothing. RETURNING the result tells JMH to keep the work.
    @Benchmark
    public String plusInLoop() {
        String s = "";
        for (int i = 0; i < n; i++) {
            s += "x";                        // each '+' makes a NEW String — O(n^2)
        }
        return s;                            // returned -> JIT can't delete the loop
    }

    @Benchmark
    public String stringBuilder() {
        StringBuilder sb = new StringBuilder(n);   // pre-size to avoid resizes
        for (int i = 0; i < n; i++) {
            sb.append('x');                  // appends into one buffer — O(n)
        }
        return sb.toString();
    }

    // When a method has no single return value, hand it to a Blackhole so
    // the JIT still believes the result is "used".
    @Benchmark
    public void consumeWithBlackhole(Blackhole bh) {
        StringBuilder sb = new StringBuilder(n);
        for (int i = 0; i < n; i++) sb.append('x');
        bh.consume(sb);                      // pretend we used it
    }
}

Benchmark                          (n)   Mode  Cnt       Score      Error  Units
StringConcatBenchmark.plusInLoop    10   avgt   20      88.413 ±    3.121  ns/op
StringConcatBenchmark.plusInLoop   100   avgt   20    6234.211 ±  214.842  ns/op
StringConcatBenchmark.plusInLoop  1000   avgt   20  583122.917 ± 9851.000  ns/op
StringConcatBenchmark.stringBuilder 10   avgt   20      32.117 ±    0.812  ns/op
StringConcatBenchmark.stringBuilder100  avgt   20     281.044 ±    7.211  ns/op
StringConcatBenchmark.stringBuilder1000 avgt   20    2715.398 ±   78.114  ns/op

# Smaller Score = faster. Error is the ± confidence interval.
# At n=1000, StringBuilder is ~215x faster than '+' in a loop.

# === Java Flight Recorder (JFR) — built into the JDK, <1% overhead ========
# Start a 60-second recording when you launch the app:
java -XX:StartFlightRecording=duration=60s,filename=app.jfr,settings=profile \
     -jar app.jar

# Or attach to an already-running JVM by its process id:
jps                                       # list Java pids
jcmd 12345 JFR.start duration=60s filename=/tmp/app.jfr settings=profile
jcmd 12345 JFR.dump  filename=/tmp/snap.jfr    # snapshot mid-flight
jcmd 12345 JFR.stop                            # stop the recording

# Read events straight from the CLI without a GUI:
jfr summary app.jfr                       # GC count, CPU load, thread totals
jfr print --events jdk.GarbageCollection app.jfr
jfr print --events jdk.ObjectAllocationSample app.jfr | head -40
jmc app.jfr                               # open in JDK Mission Control (flame graphs)

# === async-profiler — sampling CPU + allocation flame graphs (~2%) =======
# https://github.com/async-profiler/async-profiler
./asprof -d 30 -f cpu.html 12345              # 30s CPU flame graph -> HTML
./asprof -d 30 -e alloc -f alloc.html 12345   # WHERE allocations happen

# === Always-on safety net for production =================================
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/log/myapp/heap-%p.hprof \
     -Xlog:gc*:file=/var/log/myapp/gc.log:time,uptime:filecount=5,filesize=20m \
     -jar app.jar
# You get a heap dump for free if it OOMs, and a GC log to diagnose pauses.

$ jfr summary app.jfr
 Version: 2.1
 Events: 41,233

 Event Type                          Count   Size (bytes)
=====================================================
 jdk.ObjectAllocationSample          18,402        612,331
 jdk.ExecutionSample                 12,810        421,004
 jdk.GarbageCollection                  127         18,902
 jdk.GCHeapSummary                      254         40,124

# 127 GC events in 60s and allocation sampling dominating the recording
# is your first clue: this app is allocating too much, not CPU-bound.

import java.util.ArrayList;
import java.util.List;

public class Main {

    // The flame graph showed 70% of CPU in Integer.valueOf / Long boxing.
    // The culprit: a Long key forces autoboxing on EVERY map/loop touch.

    // SLOW: sum into a boxed Long. Each "+=" unboxes, adds, re-boxes a
    // brand-new Long object — millions of throwaway allocations.
    static long sumBoxed(List<Integer> data) {
        Long total = 0L;                         // boxed accumulator (bad)
        for (Integer v : data) {
            total += v;                          // unbox v, unbox total, box result
        }
        return total;
    }

    // FAST: keep the accumulator a PRIMITIVE long. Zero allocations in the
    // loop — the JIT keeps it in a CPU register.
    static long sumPrimitive(List<Integer> data) {
        long total = 0L;                         // primitive accumulator (good)
        for (Integer v : data) {
            total += v;                          // one unbox; no boxing of the sum
        }
        return total;
    }

    public static void main(String[] args) {
        List<Integer> data = new ArrayList<>();
        for (int i = 0; i < 5_000_000; i++) data.add(i);

        // Warm the JIT so we measure steady-state, not interpreter, speed.
        for (int i = 0; i < 5; i++) { sumBoxed(data); sumPrimitive(data); }

        long t0 = System.nanoTime();
        long a = sumBoxed(data);
        long boxedMs = (System.nanoTime() - t0) / 1_000_000;

        long t1 = System.nanoTime();
        long b = sumPrimitive(data);
        long primMs = (System.nanoTime() - t1) / 1_000_000;

        System.out.println("Boxed Long sum:     " + a + "  in " + boxedMs + " ms");
        System.out.println("Primitive long sum: " + b + "  in " + primMs + " ms");
        System.out.println("Speed-up:           "
                + String.format("%.1fx", (double) boxedMs / Math.max(primMs, 1)));
        System.out.println();
        System.out.println("(For publication numbers use JMH, not System.nanoTime.)");
    }
}

Boxed Long sum:     12499997500000  in 41 ms
Primitive long sum: 12499997500000  in 7 ms
Speed-up:           5.9x

(For publication numbers use JMH, not System.nanoTime.)