[ 
https://issues.apache.org/jira/browse/TINKERPOP-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1346:
----------------------------------------
    Description: 
*Reference*

Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
{code}
Assuming {{Long}} Element ids, the math says:
{code:java}
48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 bytes 
[long]) + 4 bytes + (4 bytes + 8 bytes [long])
{code}
We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
{code:java}
KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
{code}
The math says:
{code:java}
36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 8 
bytes [long]
{code}
Similar techniques would apply to {{ReferenceVertexProperty}} and 
{{ReferenceProperty}}.

*StarGraph*

Right now we serialize first the vertex, then its edges, then its properties. 
We should do vertex, properties, edges. Why? If we know that the vertex is to 
be filtered (which is an analysis of its label/id/properties), then we can skip 
over analyzing its edges. Right now, we may do all this work deserializing 
edges only to realize that the GraphFilter says that the vertex is filtered. 
Dah, pointless clock cycles – especially when edge sets can be massive.

  was:
Right now, to send a {{ReferenceEdge}} message, we serialize the form as:

{code}
KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
{code}

Assuming {{Long}} Element ids, the math says:

{code}
48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 bytes 
[long]) + 4 bytes + (4 bytes + 8 bytes [long])
{code}

We could get this smaller by not relying on Kryo's {{FieldSerializer}}.

{code}
KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
{code}

The math says:

{code}
36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 8 
bytes [long]
{code}

Similar techniques would apply to {{ReferenceVertexProperty}} and 
{{ReferenceProperty}}.


> Gryo 4.0
> --------
>
>                 Key: TINKERPOP-1346
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: io, structure
>    Affects Versions: 3.2.0-incubating
>            Reporter: Marko A. Rodriguez
>            Priority: Major
>              Labels: breaking
>
> *Reference*
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code:java}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code:java}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code:java}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code:java}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and 
> {{ReferenceProperty}}.
> *StarGraph*
> Right now we serialize first the vertex, then its edges, then its properties. 
> We should do vertex, properties, edges. Why? If we know that the vertex is to 
> be filtered (which is an analysis of its label/id/properties), then we can 
> skip over analyzing its edges. Right now, we may do all this work 
> deserializing edges only to realize that the GraphFilter says that the vertex 
> is filtered. Dah, pointless clock cycles – especially when edge sets can be 
> massive.



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

Reply via email to