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

[Bela Ban (JIRA)]

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

Bela Ban edited comment on JGRP-2043 at 7/13/16 6:09 AM:
---------------------------------------------------------

Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection.

The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.:
{code:java}
Supplier<? extends Header> supplier;
Header hdr=supplier.get();
{code}

This requires all headers to implement a Constructable interface which returns a supplier.

[1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perftests/JGroupsBenchmark.java#L97


was (Author: belaban):
Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection.

The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.:
{code:java}
Supplier<? extends Header> supplier;
Header hdr=supplier.get();
{code}

This requires all headers to implement a Creationable interface which returns a supplier.

[1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perftests/JGroupsBenchmark.java#L97

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