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 highly readable. It follows a clear, logical structure with setup, teardown, and benchmark methods organized properly. Nesting is minimal, with no deeply nested blocks. Each method has a clear purpose indicated by descriptive names (e.g., setGetLongUnsafeByteBuf). The code is concise, avoiding unnecessary verbosity while still being self-explanatory. Each functional action—such as setting up buffers, running benchmarks, and releasing resources—is placed on its own line, enhancing clarity. The reading flow is natural: package, imports, class declaration, fields, setup, teardown, and benchmarks. Minor deductions: reassigning 'unsafeBuffer' and 'byteBuffer' as fields without explicit initialization could be slightly clearer, and the benchmark methods are somewhat repetitive. Overall, it demonstrates clean, maintainable benchmark code.
Run 3
The code is well-structured and highly readable. It follows a clear package organization and logical class inheritance. Nesting is minimal, with only one level inside the class and methods. Each method has a single purpose and contains exactly one action per line, demonstrating excellent action granularity. The naming is descriptive and intent-revealing, making the purpose of each benchmark immediately clear. The setup and teardown methods are properly annotated and handle resource management correctly. Code length is concise with no unnecessary verbosity. Reading flow follows a natural order: class declaration, field declarations, setup, teardown, then benchmarks. The only minor deductions are the lack of explicit access modifiers on fields (package-private by default) and missing blank lines between methods, which slightly impact consistency, though these are stylistic preferences rather than readability issues.
Run 1
Code Structure: Clearly separates buffer fields, setup, teardown, and individual benchmarks. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the comparison being benchmarked, although constants 64, 0, and 1 lack explanatory names. Code length: Compact and free of unnecessary logic or repetition beyond the parallel benchmark cases. Action granularity: Most lines perform one action; the set/get benchmarks chain two operations, but the chains are short and understandable. Reading flow: Lifecycle methods precede benchmarks, and paired implementations support natural comparison. Minor import-spacing and grouping improvements would enhance presentation.
Run 2
Code Structure: Fields, setup, teardown, and benchmark methods are logically organized with clear separation of responsibilities. Nesting: There is no nested control flow, making every method easy to scan. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the benchmark comparisons; the unexplained constants 64, 0, and 1 slightly reduce clarity. Code length: The class is concise, with minimal boilerplate and no unnecessary logic. Action granularity: Most lines perform one action, although the set/get benchmarks chain a write and read on one line; these short chains remain understandable. Reading flow: The lifecycle methods precede paired benchmarks in a natural order. Import grouping and a blank line after the package declaration would improve visual readability.
Run 3
Code Structure: Clearly separates buffer initialization, cleanup, and benchmark methods. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the comparison being benchmarked; unexplained constants slightly reduce clarity. Code length: Concise, with minimal boilerplate and no unnecessary logic. Action granularity: Most lines perform one action, although the set/get benchmarks chain two operations on one line; these chains remain straightforward. Reading flow: Setup and teardown precede logically paired benchmarks, producing a natural progression. Import grouping and spacing could be improved slightly.