[
https://issues.apache.org/jira/browse/GEODE-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-6703:
------------------------------------
Labels: performance (was: )
> FilterRoutingInfo.readInternalDistributedMember allocations could be optimized
> ------------------------------------------------------------------------------
>
> Key: GEODE-6703
> URL: https://issues.apache.org/jira/browse/GEODE-6703
> Project: Geode
> Issue Type: Improvement
> Components: serialization
> Reporter: Darrel Schneider
> Priority: Major
> Labels: performance
>
> In running a partitioned region client/server put benchmark (with 2 servers
> and redundancy of 1), I saw that about 8% of the memory allocated on the
> server was in FilterRoutingInfo.readInternalDistributedMember.
> FilterRoutingInfo may deserialize multiple InternalDistributedMembers and
> deserializes an FilterInfo for each one BUT the only one it cares about is
> the one that is equal to its one id. It just throws away the others. It is
> possible that an optimization should happen on the sender. If we know when we
> are sending the FilterRoutingInfo who we were sending it to, then we could
> just serialize the FilterInfo for their id. This might be hard to do. At a
> high level we know who we are sending a message to but sometimes we serialize
> a message once and then send it to multiple peers.
> But another way to optimize this code is check the serialized bytes on the
> receiver for equality with our id. If they are not equal then we can just
> skip them. If they are equal then we can just use our id as the canonical id.
> I prototyped this solution in:
> 2b58f68c59ecdbd4bfdf8535bb5954d7c1f54a36
> It uses a static AtomicReference to remember myId and its serialized form.
> Since we get myId from the cache, it might be better to have it also cache
> the serialized form of myId.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
