[ 
https://issues.apache.org/jira/browse/TINKERPOP-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188712#comment-17188712
 ] 

Stephen Mallette commented on TINKERPOP-2393:
---------------------------------------------

>  But now I noticed that currently BranchStep determines if it has a barrier 
> during construction

I did a few tests and that looks like a bug. It definitely doesn't take into 
account the possibility of a {{TraversalStrategy}} adding in a {{Barrier}}. I 
think that definitely needs to get fixed. Not sure if we just cut/paste that 
block of code to {{standardAlgorithm()}} as-is though. Perhaps you could come 
up with a way to make it so that we only test 
{{getStepsOfAssignableClassRecursively(Barrier.class, traversalOption)}} once 
per child traversal and avoid it happening once per call to 
{{standardAlgorithm()}}?

> BranchStep should respect the barrier size of BarrierStep when calling 
> applyCurrentTraverser
> --------------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-2393
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-2393
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: process
>    Affects Versions: 3.4.7
>            Reporter: Norio Akagi
>            Priority: Minor
>
> Right now in BranchStep, if children contain a BarrierStep it keeps calling 
> applyCurrentTraverser until this.starts is exhausted.
> [https://github.com/apache/tinkerpop/blob/534746b6019d0775e628375a3dfeba8a18df90fe/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/branch/BranchStep.java#L139-L140]
> This means the child step may hold all upstream solutions in memory at once, 
> and potentially memory usage is bloated.
> I think here we can change so that BarrierStep can have a method like 
> getMaxBarrierSize, and BranchStep examines the size of barrier that child 
> steps can handle at once then break the while loop either when 
> `this.starts.hasNext` becomes false or we exceed the barrier size to save the 
> potential memory consumption.
>  
> When there are multiple barrier steps as children, we may pick either max or 
> min among them.
> I am happy to implement this, but please let me know if you have any comments 
> or concerns on this change. 
> Thanks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to