[
https://issues.apache.org/jira/browse/GEODE-6676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821546#comment-16821546
]
Darrel Schneider commented on GEODE-6676:
-----------------------------------------
It seems unlikely that readUTF will be called by geode code so optimizing it
may not have much of a payoff.
> org.apache.geode.internal.ByteArrayDataInput.readUTF is not optimal for ASCII
> strings
> -------------------------------------------------------------------------------------
>
> Key: GEODE-6676
> URL: https://issues.apache.org/jira/browse/GEODE-6676
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Priority: Minor
> Labels: performance
>
> org.apache.geode.internal.ByteArrayDataInput.readUTF(), given ASCII bytes,
> copies those bytes into a char array. It then allocates a new String with
> that char array.
> As of jdk 9, java.lang.String will take that char array and copy it back to a
> byte array.
> We can save a copy by using String(byte[], int, int, int). This does require
> us to do a scan to make sure all the byte values are less than 128. As soon
> as we see one that is not we can break out of the scan and do the normal utf
> encode logic. But if all our Strings are ASCII, this will save a copy and the
> char array used for UTF encoding never needs to be allocated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
