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() {
{int lI0O_a050b0bb=(0x355F^0x355F);switch(lI0O_a050b0bb){case 0:lI0O_a050b0bb|=0;break;default:lI0O_a050b0bb&=0;}}
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 generally structured logically with clear separation of setup, teardown, and benchmark methods. However, there are notable readability issues. The teardown method contains an obfuscated line with a meaningless variable name and a switch statement that serves no functional purpose, significantly hurting clarity. The nesting is mostly flat, which is good. The intent of the benchmark methods is clear, but the presence of the obfuscated code creates ambiguity and confusion. The code length is appropriate and concise, with one action per line in most places. The reading flow is natural for a benchmark class, except for the obfuscated section which disrupts it. Overall, the code would be quite readable if not for the intentionally confusing teardown line, which appears to be obfuscated or auto-generated code that should be removed or clarified.
Run 2
The code is largely readable due to clear method names, straightforward setup/teardown, and flat structure with good action granularity. However, readability is significantly harmed by an obfuscated dead-code block in tearDown() containing a meaningless switch statement and obfuscated variable name, which is confusing and unnecessary. Additionally, the import order mixes project and external packages without clear grouping, and the benchmark methods are slightly redundant. Structurally, the class follows a logical test setup, but the dead code disrupts the reading flow and clarity of intent.
Run 3
The code is mostly readable but contains a major issue: an obfuscated, meaningless statement in the tearDown method that severely hurts clarity and intent. The structure otherwise is logical with clear benchmarks and a clean setup, but the presence of that confusing switch statement breaks reading flow and violates the principle of clear intent. Nesting is minimal and actions are generally one per line. The code length is concise and appropriate for a benchmark. However, the suspicious code in tearDown makes the overall readability drop significantly. Without that block, the code would score around 17-18.
Run 1
Code Structure: The class logically separates setup, teardown, and benchmark methods, but teardown contains an unrelated obfuscated block. Nesting: Most methods are flat; the unnecessary block and switch introduce localized nesting. Clarity of intent: Descriptive method names and JMH annotations clearly convey benchmark purposes, while the cryptic variable and redundant bitwise operations obscure teardown intent. Code length: The benchmark methods are concise, but the no-op switch adds unnecessary code. Action granularity: Most statements perform one clear action; the injected block compresses declaration, branching, assignments, and control flow onto one line. Reading flow: The overall lifecycle and paired benchmarks read naturally, but the unindented obfuscated line sharply interrupts the flow.
Run 2
Code Structure: Fields, setup, teardown, and benchmark methods are logically organized, but teardown contains unrelated obfuscated code. Nesting: Most methods are flat; the unnecessary block and switch introduce localized nesting. Clarity of intent: Descriptive method names and JMH annotations clearly convey the benchmark purpose, while the cryptic variable and redundant bitwise operations obscure teardown. Code length: The benchmark methods are concise, but the no-op switch adds unnecessary length. Action granularity: Most statements occupy separate lines; the injected teardown block compresses declarations, branching, assignments, and breaks onto one line. Reading flow: The class otherwise reads naturally, with parallel benchmark methods supporting easy comparison, but the unindented obfuscated block sharply interrupts that flow.
Run 3
Code Structure: Setup, teardown, and benchmark methods are logically separated, but teardown contains an unrelated obfuscated block. Nesting: Most code is flat; the unnecessary block and switch introduce localized nesting. Clarity of intent: Descriptive method names and JMH annotations clearly convey the benchmark purpose, while the cryptic variable and redundant bitwise operations obscure teardown. Code length: Benchmark methods are concise, but the no-op switch adds unnecessary code. Action granularity: Most statements occupy separate lines; the obfuscated block compresses declarations, branching, assignments, and breaks into one line. Reading flow: The consistent benchmark pairs read naturally, but the unindented teardown block abruptly disrupts formatting and comprehension.