Uploaded image for project: 'TinkerPop'
  1. TinkerPop
  2. TINKERPOP-1164

ReducingBarriersSteps should use ComputerMemory, not MapReduce.

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Implemented
    • 3.1.0-incubating
    • 3.2.0-incubating
    • process
    • None

    Description

      This just hit me like a ton of bricks. Check this:

      g.V().count()
      

      That is:

      TraversalVertexProgram + CountMapReduce
      

      Thats stupid. Just use the "reduction" aspects of Memory. Replace CountMapReduce with:

      memory.incr("~reducing", traverser.bulk())
      

      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!

      g.V().group().by('lang').select('java').values("name")
      

      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.

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            okram Marko A. Rodriguez
            okram Marko A. Rodriguez
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment