Marko A. Rodriguez created TINKERPOP-1164:
---------------------------------------------
Summary: ReducingBarriersSteps should use ComputerMemory, not
MapReduce.
Key: TINKERPOP-1164
URL: https://issues.apache.org/jira/browse/TINKERPOP-1164
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.1.0-incubating
Reporter: Marko A. Rodriguez
This just hit me like a ton of bricks. Check this:
{code}
g.V().count()
{code}
That is:
{code}
TraversalVertexProgram + CountMapReduce
{code}
Thats stupid. Just use the "reduction" aspects of {{Memory}}. Replace
{{CountMapReduce}} with:
{code}
memory.incr("~reducing", traverser.bulk())
{code}
Thats it. Likewise for all the other reducing barriers! Now, not only do we
don't have to do a {{MapReduce}} job, we don't even have to break out of the
{{TraversalVertexProgram}} (no more "No mid-barrier steps."). Why? Well,
because its in memory, its computed on that iteration and then accessible!
{code}
g.V().group().by('lang').select('java').values("name")
{code}
That would be one TraversalVertexProgram!
.....................why do we even have MapReduce.......................... is
Memory all we really need. Crazy..............................................
thats craZy talk................................. but still, think about it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
