[jboss-jira] [JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
Bela Ban (JIRA)
issues at jboss.org
Wed Jul 13 00:47:00 EDT 2016
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264502#comment-13264502 ]
Bela Ban commented on JGRP-2043:
--------------------------------
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 onyl fast way I found so far is to create a methd 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)
More information about the jboss-jira
mailing list