You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2018/12/12 00:34:00 UTC

[jira] [Commented] (GEODE-6166) Reduce garbage production in put operation path

    [ https://issues.apache.org/jira/browse/GEODE-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16718275#comment-16718275 ] 

ASF subversion and git services commented on GEODE-6166:
--------------------------------------------------------

Commit 2d6a6177daab59d3cf6ae8c3e78a884a4e1941c2 in geode's branch refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2d6a617 ]

GEODE-6166: Improves put performance (#2970)

* Encode Operation ordinal in Message Part directly
* Don't allocate hashmap until we need it.
* Add putByte to Part and pre-allocate serialized form.
* Use Deque to avoid allocating lots of LinkedList.Node objects


> Reduce garbage production in put operation path
> -----------------------------------------------
>
>                 Key: GEODE-6166
>                 URL: https://issues.apache.org/jira/browse/GEODE-6166
>             Project: Geode
>          Issue Type: Improvement
>          Components: core
>            Reporter: Jacob S. Barrett
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> While debugging another issue I notice a less than optimal path for serializing \{{Operation}} objects during puts and destroys. The class is java.io.Serializable so it goes through  several checks to see if it can be serialized another way before falling back to Java serialization. One of these checks creates a few objects that are not necessary until later I the function but after it would short circuit for {{Operation}}. Additionally, the only member in the class that is non-transient is a byte field indicating the ordinal. This results in a 64 byte Java serialization to transmit a byte. Converting to DataSerializableFixedID poses a challenge with backwards compatibility when deserializing a message sent as Java serializable. It also costs about 4 bytes for a single byte [DSCODE (byte) + FIXED-ID (short) + VALUE (byte)]. Writing a single byte to the message part costs a single byte and makes detecting old clients sending objects trivial. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)