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 set() {
unsafeBuffer = new UnpooledUnsafeDirectByteBuf(UnpooledByteBufAllocator.DEFAULT, 64, 64);
byteBuffer = ByteBuffer.allocateDirect(64);
}
@TearDown
public void tear() {
unsafeBuffer.release();
}
@Benchmark
public long set2() {
return unsafeBuffer.setLong(0, 1).getLong(0);
}
@Benchmark
public long set3() {
return byteBuffer.putLong(0, 1).getLong(0);
}
@Benchmark
public ByteBuf set4() {
return unsafeBuffer.setLong(0, 1);
}
@Benchmark
public ByteBuffer set5() {
return byteBuffer.putLong(0, 1);
}
}
Run 1
The code is well-structured and readable. It follows a clear benchmark class pattern with standard JMH annotations. The structure is logical: field declarations, setup/teardown methods, then benchmark methods. Nesting is minimal and flat. Intent is clear despite generic method names (set2, set3, etc.) that lack descriptive purpose. Code length is concise and appropriate for benchmarking. Action granularity is good - each benchmark method contains a single chained operation. Reading flow is natural, progressing from setup to benchmarks. The main readability weakness is the vague method naming convention (set2, set3, set4, set5), which obscures what each benchmark actually measures. Additionally, there's a minor inconsistency where one @Benchmark method returns ByteBuf while another returns ByteBuffer, though this appears intentional for comparing buffer types.
Run 2
The code is well-structured and highly readable. It has a clear logical organization with setup, teardown, and benchmark methods properly separated. Nesting is minimal, with no deep conditional blocks or loops. Intent is crystal clear: benchmarking direct buffer operations. Code length is appropriate and concise, with no unnecessary verbosity. Each line performs a single action, maintaining good action granularity. The reading flow is natural, following a logical progression from initialization to benchmark methods. Minor deductions: method names like set2(), set3() could be more descriptive, and there's slight inconsistency in naming the teardown method (tear vs setUp/tearDown convention). The imports are all necessary and well-organized. Overall, this code exemplifies clean, maintainable structure typical of microbenchmark harnesses.
Run 3
The code is well-structured and readable. It is logically organized with clear separation of setup, teardown, and benchmark methods. Nesting is minimal, with no deeply nested blocks. Intent is fairly clear—benchmarking Unsafe ByteBuf operations against ByteBuffer—though method names like set2, set3, etc., are ambiguous and could be more descriptive. Code length is concise and appropriate. Action granularity is good: each benchmark method performs one logical action. Reading flow is natural, with methods arranged in a logical order. The only notable improvement would be more meaningful benchmark method names.
Run 1
Code Structure: Setup, teardown, and benchmark methods are clearly separated, though import grouping could improve. Nesting: No nested control flow makes the code easy to scan. Clarity of intent: JMH annotations establish the benchmark purpose, but names such as set2 through set5 obscure which buffer and operation each method tests; repeated numeric literals lack descriptive constants. Code length: Short and focused, with little unnecessary code. Action granularity: Most lines perform one action, but set2 and set3 chain a write and read in a single expression. Reading flow: Initialization followed by cleanup and benchmarks is logical, and paired buffer operations are easy to compare, although descriptive method names would make the flow more self-explanatory.
Run 2
Code Structure: Fields, setup, teardown, and benchmark methods are logically organized and clearly separated. Nesting: The code is flat, with no nested control flow. Clarity of intent: JMH annotations establish the benchmarking purpose, but names such as set2 through set5 obscure which operation and buffer implementation each method measures; set and tear are also vague. Code length: The class is concise, with little unnecessary code. Action granularity: Most lines perform one action, although set2 and set3 chain a write and read on the same line. Reading flow: The lifecycle-to-benchmarks sequence is natural, but cryptic method names, repeated numeric literals, and ungrouped imports slightly hinder scanning.
Run 3
Code Structure: Fields, setup, teardown, and benchmarks are logically organized into small methods. Nesting: Entirely flat, making control flow easy to follow. Clarity of intent: JMH annotations clearly identify lifecycle and benchmark methods, but names like set2, set3, set4, and set5 do not describe the operations or buffer types being compared. Repeated literals also lack explanatory names. Code length: Compact with little unnecessary code. Action granularity: Most lines perform one action, although set2 and set3 chain a write and read on the same line. Reading flow: The lifecycle-to-benchmarks sequence is natural, but opaque method names and unseparated import groups slightly hinder scanning.