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 with clear separation of setup, teardown, and benchmark methods. It maintains a flat hierarchy with minimal nesting, making it easy to follow. Naming is descriptive, and each benchmark method has a single, obvious purpose. Lines are concise, typically performing one action, which improves readability. The reading flow is natural: imports, class declaration, field declarations, setup/teardown, then benchmarks. Minor deductions: the setup doesn't explicitly clear or reset the ByteBuffer between benchmarks (implicit order dependency), and the @Benchmark methods are nearly identical, which could confuse intent without deeper context. Overall, the code is highly readable, concise, and follows typical JMH benchmark conventions.
Run 3
The code is well-structured, with clear separation of setup, teardown, and benchmark methods. It is flat with no nesting, making control flow easy to follow. Intent is obvious from method names and annotations. The code is concise, with one action per line in each benchmark method. Reading flow is natural: fields, setup, teardown, then benchmarks in logical order. Minor deductions: the allocation of the unsafe buffer uses a constructor directly rather than a factory, which slightly reduces abstraction, but this is acceptable for a microbenchmark.
Run 1
Code Structure: Clearly separates buffer fields, setup, teardown, and benchmark methods. Nesting: Flat methods with no nested control flow. Clarity of intent: Descriptive method names and JMH annotations make the comparison between buffer implementations clear; unnamed constants slightly reduce clarity. Code length: Concise, with minimal boilerplate and no unnecessary logic. Action granularity: Most lines perform one action, although set/get benchmarks chain a write and read on the same line. Reading flow: Natural lifecycle-to-benchmarks ordering and consistent formatting make the code easy to follow; import grouping could be improved.
Run 2
Code Structure: Fields, setup, teardown, and benchmark methods are logically organized, with parallel methods making comparison easy. Nesting: No nested control flow; all methods are flat. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the benchmark purpose, though unexplained constants (64, 0, and 1) slightly reduce clarity. Code length: Concise, with no unnecessary logic or boilerplate beyond the benchmark framework requirements. Action granularity: Most lines perform one action; the set/get benchmarks chain two operations on one line, but this remains easy to understand. Reading flow: The lifecycle methods precede the benchmarks naturally, and consistent formatting supports scanning. Import grouping and spacing could be improved slightly.
Run 3
Code Structure: Setup, teardown, and benchmark methods are clearly separated and logically organized. Nesting: Methods are flat, with no nested control flow. Clarity of intent: JMH annotations and descriptive method names make the buffer-operation comparison clear; unexplained literals slightly reduce clarity. Code length: The class is concise, with little unnecessary code. Action granularity: Most lines perform one action, although the set/get benchmarks chain a write and read on one line; this remains easy to understand. Reading flow: Initialization precedes cleanup and benchmarks, and comparable operations are grouped naturally. Import grouping and a blank line after the package declaration would improve presentation.