[
https://issues.apache.org/jira/browse/GIRAPH-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103363#comment-13103363
]
Jake Mannix commented on GIRAPH-28:
-----------------------------------
As for sorting, I'd imagine that assuming it always returns a sorted iterator
is fine, but yes, some implementations I can imagine might not want to do that.
I'd lean against having multiple iterators until it was known that they were
needed, and maybe just document the ones which return nonsorted ones so that
things don't get messed up?
Vertex subclasses are where the "algorithms" are implemented, right? So a
Vertex knows whether it has a sorted iterator or not... the only question would
be: are there generic methods implemented in things like BspServiceWorker, or
GraphMapper, which would be expected to need to do things to a sorted iterator?
Currently there are no such places that I can see. Without such cases, we
could easily leave Vertex implementations to decide whether they needed to
return sorted iterators or not.
> Introduce new primitive-specific MutableVertex subclasses
> ---------------------------------------------------------
>
> Key: GIRAPH-28
> URL: https://issues.apache.org/jira/browse/GIRAPH-28
> Project: Giraph
> Issue Type: New Feature
> Components: graph
> Affects Versions: 0.70.0
> Reporter: Jake Mannix
> Assignee: Jake Mannix
> Attachments: GIRAPH-28.diff, GIRAPH-28.diff
>
>
> As discussed on the list,
> MutableVertex<LongWritable,DoubleWritable,FloatWritable,DoubleWritable> (for
> example) could be highly optimized in its memory footprint if the vertex and
> edge data were held in a form which minimized Java object usage.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
