[
https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-2043:
--------------------------------
OK, created my own JMH test. MethodHandle.invokeExact() [1] showed the best perf, almost
the same as directly calling the constructor:
{noformat}
Benchmark Mode Cnt Score Error
Units
JGroupsBenchmark.createNormal avgt 5 25.426 ± 1.108
ns/op
JGroupsBenchmark.createWithConstructor avgt 5 271.742 ± 13.169
ns/op
JGroupsBenchmark.createWithMethodHandle avgt 5 266.403 ± 11.437
ns/op
JGroupsBenchmark.createWithMethodHandleInvokeExact avgt 5 25.102 ± 1.060
ns/op
JGroupsBenchmark.createWithMethodHandleInvokeExactAsType avgt 5 24.814 ± 1.085
ns/op
JGroupsBenchmark.createWithReflection avgt 5 302.597 ± 7.962
ns/op
{noformat}
[1]
https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte...
Improve performance of Message#readHeader
-----------------------------------------
Key: JGRP-2043
URL:
https://issues.jboss.org/browse/JGRP-2043
Project: JGroups
Issue Type: Enhancement
Reporter: Sanne Grinovero
Assignee: Bela Ban
Priority: Minor
Fix For: 4.0
A CPU hot spot highlighed by profiling via JFR:
{noformat}Stack Trace Sample Count Percentage(%)
java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
java.lang.Class.newInstance() 71 2.392
org.jgroups.Message.readHeader(DataInput) 71 2.392
{noformat}
I'd have expected the reflective constructor to perform well on a recent JVM, but
apparently it's not in this case. A theory is that the {{Class}} type being unknown
makes this code harder to optimise; needs to be looked into.
It might be possible to patch the {{ClassConfigurator}} to provide instances of the
required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)