[KAFKA-8563] Minor: Remove method call in networkSend. Rely on java's vargs boxing/autoboxing

• Type: Improvement
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.4.0
• Fix Version/s: 2.4.0
• Component/s: clients

Environment

Darwin WM-CXXXXXX 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64

ProductName: Mac OS X
ProductVersion: 10.14.3

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

• Assignee: Unassigned
• Reporter: karan kumar
• Created: 19/Jun/19 05:54
• Updated: 21/Jun/19 17:11
• Resolved: 21/Jun/19 17:11

Description

There was a  https://github.com/apache/kafka/blob/93bf96589471acadfb90e57ebfecbd91f679f77b/clients/src/main/java/org/apache/kafka/common/network/NetworkSend.java#L30 which can be removed from the network send class. 

 

Initial JMH benchmarks suggest no performance penalty.

 

Present network send JMH report:

 

jmh-benchmarks git:(trunk) ✗ ./jmh.sh -f 2 ByteBufferSendBenchmark
running gradlew :jmh-benchmarks:clean :jmh-benchmarks:shadowJar in quiet mode
./jmh.sh: line 34: ../gradlew: No such file or directory
gradle build done
running JMH with args [-f 2 ByteBufferSendBenchmark]
# JMH version: 1.21
# VM version: JDK 1.8.0_201, Java HotSpot(TM) 64-Bit Server VM, 25.201-b09
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre/bin/java
# VM options: <none>
# Warmup: 5 iterations, 2000 ms each
# Measurement: 5 iterations, 5000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.apache.kafka.jmh.common.ByteBufferSendBenchmark.benchmarkMethod

# Run progress: 0.00% complete, ETA 00:01:10
# Fork: 1 of 2
# Warmup Iteration 1: 35.049 ops/us
# Warmup Iteration 2: 60.877 ops/us
# Warmup Iteration 3: 59.207 ops/us
# Warmup Iteration 4: 59.077 ops/us
# Warmup Iteration 5: 59.327 ops/us
Iteration 1: 58.516 ops/us
Iteration 2: 58.952 ops/us
Iteration 3: 58.596 ops/us
Iteration 4: 59.126 ops/us
Iteration 5: 58.557 ops/us

# Run progress: 50.00% complete, ETA 00:00:35
# Fork: 2 of 2
# Warmup Iteration 1: 36.377 ops/us
# Warmup Iteration 2: 61.741 ops/us
# Warmup Iteration 3: 59.683 ops/us
# Warmup Iteration 4: 59.571 ops/us
# Warmup Iteration 5: 59.351 ops/us
Iteration 1: 59.044 ops/us
Iteration 2: 59.107 ops/us
Iteration 3: 57.771 ops/us
Iteration 4: 59.648 ops/us
Iteration 5: 59.408 ops/us


Result "org.apache.kafka.jmh.common.ByteBufferSendBenchmark.benchmarkMethod":
58.872 ±(99.9%) 0.806 ops/us [Average]
(min, avg, max) = (57.771, 58.872, 59.648), stdev = 0.533
CI (99.9%): [58.066, 59.679] (assumes normal distribution)


# Run complete. Total time: 00:01:11

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

Benchmark Mode Cnt Score Error Units
*ByteBufferSendBenchmark.benchmarkMethod thrpt 10 58.872 ± 0.806 ops/us*
JMH benchmarks done

and after removing the method call

 

// code placeholder

./jmh.sh: line 34: ../gradlew: No such file or directory
gradle build done
running JMH with args [-f 2 ByteBufferSendBenchmark]
# JMH version: 1.21
# VM version: JDK 1.8.0_201, Java HotSpot(TM) 64-Bit Server VM, 25.201-b09
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre/bin/java
# VM options: <none>
# Warmup: 5 iterations, 2000 ms each
# Measurement: 5 iterations, 5000 ms each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.apache.kafka.jmh.common.ByteBufferSendBenchmark.benchmarkMethod

# Run progress: 0.00% complete, ETA 00:01:10
# Fork: 1 of 2
# Warmup Iteration 1: 34.273 ops/us
# Warmup Iteration 2: 61.565 ops/us
# Warmup Iteration 3: 59.307 ops/us
# Warmup Iteration 4: 57.081 ops/us
# Warmup Iteration 5: 59.970 ops/us
Iteration 1: 59.657 ops/us
Iteration 2: 59.607 ops/us
Iteration 3: 59.931 ops/us
Iteration 4: 59.871 ops/us
Iteration 5: 59.504 ops/us

# Run progress: 50.00% complete, ETA 00:00:35
# Fork: 2 of 2
# Warmup Iteration 1: 38.849 ops/us
# Warmup Iteration 2: 62.525 ops/us
# Warmup Iteration 3: 58.492 ops/us
# Warmup Iteration 4: 59.954 ops/us
# Warmup Iteration 5: 60.017 ops/us
Iteration 1: 59.819 ops/us
Iteration 2: 60.102 ops/us
Iteration 3: 60.195 ops/us
Iteration 4: 59.975 ops/us
Iteration 5: 60.159 ops/us


Result "org.apache.kafka.jmh.common.ByteBufferSendBenchmark.benchmarkMethod":
59.882 ±(99.9%) 0.359 ops/us [Average]
(min, avg, max) = (59.504, 59.882, 60.195), stdev = 0.237
CI (99.9%): [59.523, 60.241] (assumes normal distribution)


# Run complete. Total time: 00:01:11

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

Benchmark Mode Cnt Score Error Units
*ByteBufferSendBenchmark.benchmarkMethod thrpt 10 59.882 ± 0.359 ops/us*
JMH benchmarks done

 

Issue Links

• links to: GitHub Pull Request #6967