You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (JIRA)" <ji...@apache.org> on 2019/04/18 22:45:00 UTC

[jira] [Commented] (GEODE-6676) org.apache.geode.internal.ByteArrayDataInput.readUTF is not optimal for ASCII strings

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