[
https://issues.apache.org/jira/browse/TINKERPOP-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094998#comment-15094998
]
Marko A. Rodriguez commented on TINKERPOP-379:
----------------------------------------------
This seems overly complicating.
Problems:
* {{MessageCombiners}} will have to know how to deal with these static messages.
* You never know the order you get messages in so if you need to have the
static message first before processing other messages you are hosed.
** Developers will have to maintain a list of all such messages up till the
static message arrives (memory issues).
Next, this doesn't need to be a special method. If someone has a
{{VertexProgram}} that can do some initialization messages in the first round
along with some data messages, then they will be smart to make their
{{MessageCombiner}} do as expected as well as dealing with out of order
messages.
> MessageScope.Local.setStaticMessage(M msg)
> ------------------------------------------
>
> Key: TINKERPOP-379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-379
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.2-incubating
> Reporter: Matthias Broecheler
> Assignee: Marko A. Rodriguez
> Fix For: 3.1.1-incubating
>
>
> A special variant of a local message scope should be introduced where the
> message is fixed (which could be achieved through a message call above).
> Such MessageScopes would be restricted in that only the configured message
> would be allowed. The benefit of this special case is that it allows
> GraphComputers to execute such messages much more efficiently.
> For instance, for PageRankVertexProgram there is the countMessageScope which
> has a static message (1.0d) which is used for degree counting. If a
> VertexProgram only has a static message scope for a particular iteration,
> then the GraphComputer can execute two iterations at once. The given
> iteration (where only this static message can be send, and hence nothing
> needs to be send at all) and the next iteration where calling receive would
> return the static message.
> On large graphs that can make a significant performance difference for simple
> jobs like degree counting. For GraphComputer implementations that require
> scanning the entire graph (Hadoop, Fulgora) this makes a tremendous
> difference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
