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 has readable method names and logical separation of benchmarks, but suffers from poor formatting. Imports are crammed on one line, method declarations and bodies are inconsistently formatted, and some blocks are compressed onto single lines. The setup and teardown methods are clear in intent, but the action granularity is inconsistent - some lines contain multiple statements while others are broken naturally. Nesting is minimal, which is good, but the reading flow is disrupted by inconsistent indentation and spacing. The class structure follows a reasonable pattern for JMH benchmarks, with setup, teardown, and benchmark methods clearly named. However, the formatting issues make the code unnecessarily difficult to scan and maintain. Overall structure is acceptable but execution of formatting significantly hurts readability.
Run 2
The code has significant readability issues. Multiple statements are packed onto single lines (e.g., imports and field declarations), violating the 'one action per line' principle. Some methods are compressed into one-liners, reducing clarity and disrupting natural reading flow. The setup method combines object initialization and direct buffer allocation without separation. Inconsistent brace placement and indentation (e.g., tearDown method has a closing brace on the same line) further hurt structure. However, method names are descriptive and the overall logic is straightforward, which partially mitigates these problems. The code is functional but poorly formatted for readability.
Run 3
The code is generally readable but formatted inconsistently. The class is logically organized and methods are short, but the import section and some method declarations are crammed onto single lines. Nesting is flat, which helps clarity, and each benchmark method indicates its intent through method naming. However, variable declarations and some methods are placed on one line, reducing readability. The overall structure is understandable but not cleanly formatted. Improved line breaks and consistent spacing would raise the score.
Run 1
Code Structure: Setup, teardown, and benchmark methods are logically separated, but compressed imports, fields, and method boundaries weaken visual organization. Nesting: Very shallow, with no nested control flow, making methods easy to follow. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the benchmark purpose; numeric literals provide little context. Code length: Short and appropriately concise, without unnecessary logic. Action granularity: Several declarations and structural elements share lines, reducing scanability; chained set/get operations are compact but understandable. Reading flow: The lifecycle-to-benchmark sequence is natural, but inconsistent brace placement and annotations attached to adjacent code interrupt reading.
Run 2
Code Structure: Setup, teardown, and benchmark methods are logically separated, but compressed imports and inconsistent formatting obscure that organization. Nesting: Methods are flat, with no nested control flow, making them easy to follow. Clarity of intent: Descriptive class and method names clearly convey the buffer comparison; unexplained numeric constants slightly reduce clarity. Code length: The implementation is concise without unnecessary logic. Action granularity: Multiple imports and field declarations share lines, while annotations, braces, and statements are inconsistently combined; chained operations remain understandable. Reading flow: The lifecycle-to-benchmark sequence is natural, but irregular line breaks and brace placement interrupt scanning. Overall, straightforward logic and clear naming provide moderate readability despite poor formatting.
Run 3
Code Structure: The class logically separates setup, teardown, and benchmark methods, but compressed imports, declarations, and method boundaries weaken organization. Nesting: Methods are flat with no complex control flow, making them easy to understand. Clarity of intent: Descriptive method names and JMH annotations clearly communicate the benchmarking purpose, though literal values lack context. Code length: The implementation is concise without unnecessary logic, but excessive formatting compression hurts readability. Action granularity: Several imports and field declarations share lines, and chained write/read operations combine actions, although those chains suit the benchmarks. Reading flow: Inconsistent brace placement and annotations sharing lines with method declarations or preceding closing braces interrupt scanning. Overall, simple logic and clear naming provide reasonable readability despite poor formatting.