[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Sanne Grinovero edited comment on ISPN-2133 at 5/30/17 11:23 AM: ----------------------------------------------------------------- One more thought: traditionally such problems are solved by Java's standard Serialization. Imagine you're sending in bulk / batches, writing many objects which have some large string in common, or sharing any other large object. Standard serialization - including JBoss Marshalling - already do support object graphs and therefore re-materialize the object as one. So it could be that serializing all values of a batch / transaction / queue of operations into one single Blob is much more efficient than serializing multiple commands independently and pack them together after individual serialization; if we could improve on this, we'd be able to reap benefits at basically no API change cost. Incidentally there would be two benefits: * smaller payload on the wire * smaller heap consumption on the receiver's size, as same objects would be deserialized "as one" rather than being materialized as multiple copies Thinking about this, it implies that Infinispan might have a problem with "size amplification": if I estimate my object size locally to try to estimate how much space my data grid will need, I'm doing it wrong as the estimate we'd do today would not take into account of this size amplification. was (Author: sannegrinovero): One more thought: traditionally such problems are solved by Java's standard Serialization. Imagine you're sending in bulk / batches, writing many objects which have some large string in common, or sharing any other large object. Standard serialization - including JBoss Marshalling - already do support object graphs and therefore re-materialize the object as one. So it could be that serializing all values into one single Blob is much more efficient than serializing multiple commands independently; if we could do that, we'd be able to reap benefits at basically no API change cost. Incidentally there would be two benefits: * smaller payload on the wire * smaller heap consumption on the receiver's size, as same objects would be deserialized "as one" rather than being materialized as multiple copies Thinking about this, it implies that Infinispan might have a problem with "size amplification": if I estimate my object size locally to try to estimate how much space my data grid will need, I'm doing it wrong as the estimate we'd do today would not take into account of this size amplification. -- This message was sent by Atlassian JIRA (v7.2.3#72005)