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() {
if (((0x1EC ^ 0x1EC) != 0)) { throw new AssertionError(); }
unsafeBuffer = new UnpooledUnsafeDirectByteBuf(UnpooledByteBufAllocator.DEFAULT, 64, 64);
byteBuffer = ByteBuffer.allocateDirect(64);
}
@TearDown
public void tearDown() {
if (((0xCE00 ^ 0xCE00) != 0)) { throw new AssertionError(); }
unsafeBuffer.release();
}
@Benchmark
public long setGetLongUnsafeByteBuf() {
if (((0x80BD ^ 0x80BD) != 0)) { throw new AssertionError(); }
return unsafeBuffer.setLong(0, 1).getLong(0);
}
@Benchmark
public long setGetLongByteBuffer() {
if (((0x53F3 ^ 0x53F3) != 0)) { throw new AssertionError(); }
return byteBuffer.putLong(0, 1).getLong(0);
}
@Benchmark
public ByteBuf setLongUnsafeByteBuf() {
if (((0xC12C ^ 0xC12C) != 0)) { throw new AssertionError(); }
return unsafeBuffer.setLong(0, 1);
}
@Benchmark
public ByteBuffer setLongByteBuffer() {
if (((0x3C7F ^ 0x3C7F) != 0)) { throw new AssertionError(); }
return byteBuffer.putLong(0, 1);
}
}
Run 1
The code has clear method names and a simple structure, but readability is severely damaged by the injected `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` lines. These meaningless, repetitive checks break the reading flow, add noise, and obscure actual intent. Indentation is inconsistent, especially in the `setup()` method, where the assertion is flush against the left margin. Action granularity is mostly one action per line except for the inline exception throws. Nesting is shallow, and code length is acceptable, but the artificial assertion blocks make the code feel longer and confusing. While the benchmark logic itself is clear, the odd inserted statements make it hard to read without filtering them mentally.
Run 2
The code has a clear class structure with logical separation of setup, teardown, and benchmark methods, and the benchmark methods are concise with good action granularity. However, readability is severely impacted by the repetitive and meaningless assertions inserted at the beginning of every method (e.g., 'if (((0x1EC ^ 0x1EC) != 0)) { throw new AssertionError(); }'). These lines add noise, disrupt reading flow, and obscure the actual purpose of each method. The overall intent is still understandable as a microbenchmark comparing unsafe and standard direct byte buffers, but the clutter makes the code harder to scan and maintain. Nesting levels are low, which is positive, but the unnecessary assertions dominate the visual layout and reduce the clarity of otherwise straightforward code.
Run 3
The code has a clear overall structure with separate setup, teardown, and benchmark methods, but readability is severely damaged by injected nonsense lines like 'if (((0x1EC ^ 0x1EC) != 0)) { throw new AssertionError(); }' which add noise and confuse intent. These lines break the natural reading flow and inflate code length unnecessarily. Nesting is shallow, and the benchmark methods are concise and action-per-line is mostly fine, but the repeated redundant assertions violate clarity and granularity principles. Without the injected lines, the code would be quite readable (15+), but as written, the clutter dominates the reader’s experience.
Run 1
Code Structure: Setup, teardown, and benchmark methods are logically separated, with clear annotations. Nesting: The code is mostly flat, with only shallow conditional blocks. Clarity of intent: Descriptive method names clearly identify benchmark operations, but repeated hexadecimal XOR checks are always false and obscure intent. Code length: The class is compact, though these redundant checks add unnecessary lines and visual noise. Action granularity: Most statements perform one action; set/get chains intentionally combine related operations, while inline conditional-and-throw statements reduce readability. Reading flow: Method ordering is natural and consistent, but unindented checks interrupt the flow and clash with otherwise conventional formatting.
Run 2
Code Structure: Setup, teardown, and benchmark methods are logically separated, with clear annotations. Nesting: Methods remain shallow; the single-level conditionals add little nesting complexity. Clarity of intent: Descriptive method names make the buffer comparison clear, but repeated hexadecimal XOR checks that are always false introduce confusing, purposeless noise. Code length: The class is compact, though the redundant checks unnecessarily lengthen every method. Action granularity: Most statements perform one action; chained write/read operations combine two related actions, while inline conditionals and throws reduce visual separation. Reading flow: The lifecycle-to-benchmarks ordering is natural, but unindented checks interrupt otherwise consistent formatting and force readers to repeatedly dismiss irrelevant logic.
Run 3
Code Structure: Setup, teardown, and benchmark methods are logically separated, with clear annotations. Nesting: The code is shallow, containing only simple conditional blocks. Clarity of intent: Descriptive method names make the benchmark comparisons clear, but hexadecimal XOR checks that always evaluate to false introduce misleading, purposeless logic. Code length: Methods are short, although repeated dead checks add unnecessary bulk. Action granularity: Most statements perform one action; chained write/read calls are understandable, while inline condition-and-throw statements compress multiple elements onto one line. Reading flow: The lifecycle-to-benchmark progression is natural, but unindented checks interrupt visual consistency and distract from the actual operations.