[jboss-jira] [JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader

Bela Ban (JIRA) issues at jboss.org
Tue Jul 12 10:31:00 EDT 2016


    [ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264280#comment-13264280 ] 

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/perftests/JGroupsBenchmark.java#L84

> 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)



More information about the jboss-jira mailing list