Source code
package io.netty.microbench.buffer;
import io.netty.buffer.ByteBuf;
import io.netty.buffer.UnpooledByteBufAllocator;
import io.netty.buffer.UnpooledUnsafeDirectByteBuf;
import io.netty.microbench.util.AbstractMicrobenchmark;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.TearDown;
import java.nio.ByteBuffer;
public class UnsafeByteBufBenchmark extends AbstractMicrobenchmark {
private ByteBuf unsafeBuffer;
private ByteBuffer byteBuffer;
@Setup
public void setup() {
unsafeBuffer = new UnpooledUnsafeDirectByteBuf(UnpooledByteBufAllocator.DEFAULT, 64, 64);
byteBuffer = ByteBuffer.allocateDirect(64);
}
@TearDown
public void tearDown() {
unsafeBuffer.release();
}
@Benchmark
public long setGetLongUnsafeByteBuf() {
return unsafeBuffer.setLong(0, 1).getLong(0);
}
@Benchmark
public long setGetLongByteBuffer() {
return byteBuffer.putLong(0, 1).getLong(0);
}
@Benchmark
public ByteBuf setLongUnsafeByteBuf() {
return unsafeBuffer.setLong(0, 1);
}
@Benchmark
public ByteBuffer setLongByteBuffer() {
return byteBuffer.putLong(0, 1);
}
}
Run 1
The code is well-structured with clear separation of setup, benchmark methods, and teardown. The class is concise and avoids unnecessary complexity. Each benchmark method is a single line, demonstrating good action granularity. Nesting is minimal—only one level of class and method definitions. Intent is clear from method names like 'setGetLongUnsafeByteBuf' versus 'setGetLongByteBuffer', making the comparison obvious. Reading flow is natural, moving from setup to benchmarks to teardown. Minor deductions: the class name could be slightly more specific (e.g., include 'SetGetLong' if only testing longs), and there's no validation of buffer capacity in setup, but these are trivial. The code is highly readable and follows common benchmarking patterns.
Run 2
The code is well-structured and highly readable. It has a clear class hierarchy (extends AbstractMicrobenchmark), logical imports, and a clean separation of setup, teardown, and benchmark methods. Nesting is flat—there are no nested conditionals or loops. Each benchmark method has a clear, unambiguous name that describes exactly what it tests. The code is concise, with no unnecessary length. Action granularity is appropriate, with one meaningful operation per line inside the benchmark methods. Reading flow is natural: setup initializes resources, benchmarks execute, teardown releases the buffer. Minor deductions: the missing visibility modifier on the 'unsafeBuffer' and 'byteBuffer' fields (package-private) could be ambiguous in intent; also, there is slight duplication in naming (e.g., 'setGetLongUnsafeByteBuf' vs 'setGetLongByteBuffer'), though this mirrors JMH conventions and is acceptable.
Run 3
The code is well-structured and highly readable. It follows a logical organization with clear class setup, imports, and method separation. Nesting is minimal, with no deep indentation levels. Each benchmark method clearly communicates its intent through descriptive naming, such as 'setGetLongUnsafeByteBuf' and 'setLongByteBuffer'. The code length is appropriate for its purpose—no unnecessary verbosity. Action granularity is proper: each method performs a single logical operation, and chained calls like 'setLong(0, 1).getLong(0)' are concise while remaining clear. Reading flow is natural, moving from setup to benchmark methods to teardown. Minor deductions could be made for slightly repetitive benchmark method names and the one-line import block, which slightly reduces scanability. Overall, this is exemplary code for a microbenchmark.
Run 1
Code Structure: Well organized into fields, setup, teardown, and focused benchmark methods. Nesting: Flat methods with no nested control flow. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the comparison between unsafe ByteBuf and ByteBuffer operations; unexplained literals slightly reduce clarity. Code length: Concise, with little unnecessary code. Action granularity: Most lines perform one action, although set/get benchmarks chain two operations on a single line; these chains remain easy to understand. Reading flow: Natural lifecycle-first organization followed by paired benchmarks makes comparison straightforward. Import grouping and named constants for buffer size and test values would modestly improve readability.
Run 2
Code Structure: Setup, teardown, and benchmark methods are logically separated, with parallel methods making comparisons straightforward. Nesting: Methods are flat, with no conditional or loop nesting. Clarity of intent: JMH annotations and descriptive method names clearly convey the benchmarking purpose, though constants such as 64, 0, and 1 are unexplained. Code length: The implementation is concise and contains little unnecessary code. Action granularity: Most statements perform one action; the set/get benchmarks chain two operations on one line, but the short expressions remain easy to understand. Reading flow: Execution flows naturally from initialization to cleanup and benchmark operations. Import grouping and spacing could be improved, and grouping benchmarks consistently by operation or buffer type would slightly strengthen readability.
Run 3
Code Structure: Clearly separates buffer setup, cleanup, and individual benchmarks. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive method names and JMH annotations clearly identify the operations being compared, though literals 64, 0, and 1 lack explanatory names. Code length: Compact without unnecessary abstraction or repetition beyond the parallel benchmark methods. Action granularity: Most lines perform one action; the set/get benchmarks chain two operations on one line, but their method names make this understandable. Reading flow: Setup and teardown precede the benchmarks, and related operations are grouped naturally. Import grouping and spacing could be slightly cleaner.