[jira] [Closed] (TINKERPOP-379) MessageScope.Local.setStaticMessage(M msg)

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

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

Marko A. Rodriguez closed TINKERPOP-379.
----------------------------------------
    Resolution: Won't Fix

Closing at this is something that should be handled on a per {{VertexProgram}} implementation level and doesn't need a special method in TinkerPop3 API.

> 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)