[
https://issues.apache.org/jira/browse/TINKERPOP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060888#comment-16060888
]
ASF GitHub Bot commented on TINKERPOP-1682:
-------------------------------------------
Github user dkuppitz commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/621#discussion_r123745535
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/GroupStep.java
---
@@ -79,6 +79,14 @@ public void modulateBy(final Traversal.Admin<?, ?>
kvTraversal) {
}
@Override
+ public void replaceLocalChild(final Traversal.Admin<?, ?>
oldTraversal, final Traversal.Admin<?, ?> newTraversal) {
+ if (null != this.keyTraversal &&
this.keyTraversal.equals(oldTraversal))
+ this.keyTraversal = this.integrateChild(newTraversal);
+ else if (null != this.valueTraversal &&
this.valueTraversal.equals(oldTraversal))
--- End diff --
No, that's what I'm saying. Think about the scenarios in which this
strategy kicks in. It will only replace the traversal, if there's a single step
(`id()` or `label()`, later possibly also `key()` or `value()`).
Now, looking at the barrier manipulation code:
```
this.barrierStep =
TraversalHelper.getFirstStepOfAssignableClass(Barrier.class,
this.valueTraversal).orElse(null);
```
There will never be a `BarrierStep`, hence `this.barrierStep` will always
be and will stay `null`.
```
this.setReducingBiOperator(new GroupBiOperator<>(null == this.barrierStep ?
Operator.assign : this.barrierStep.getMemoryComputeKey().getReducer()));
```
Since `this.barrierStep` will always be `null`, the reducing operator will
always be (and stay) `assign`.
> by-modulator optimization strategy
> ----------------------------------
>
> Key: TINKERPOP-1682
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1682
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.4
> Reporter: Daniel Kuppitz
> Assignee: Daniel Kuppitz
>
> The can be a significant difference in performance depending on whether you
> use {{by(id)}} or {{by(id())}}:
> {noformat}
> gremlin> g.V().out().in().path().by(id()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms) % Dur
> =============================================================================================================
> TinkerGraphStep(vertex,[]) 6
> 6 12.137 58.03
> VertexStep(OUT,vertex) 6
> 6 1.345 6.43
> VertexStep(IN,vertex) 12
> 12 0.861 4.12
> PathStep([[IdStep, ProfileStep]]) 12
> 12 6.570 31.42
> IdStep 36
> 36 0.452
> >TOTAL -
> - 20.916 -
> gremlin> g.V().out().in().path().by(id).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms) % Dur
> =============================================================================================================
> TinkerGraphStep(vertex,[]) 6
> 6 0.876 11.54
> VertexStep(OUT,vertex) 6
> 6 0.714 9.40
> VertexStep(IN,vertex) 12
> 12 3.299 43.43
> PathStep([id]) 12
> 12 2.706 35.63
> >TOTAL -
> - 7.596 -
> {noformat}
> We should have a strategy that rewrites these simple patterns. This affects
> {{id()}}, {{label()}}, {{key()}}, {{value()}}, but also
> {{by(values("name"))}}, which can be rewritten as {{by("name")}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
