[
https://issues.apache.org/jira/browse/TINKERPOP-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cameron Fiander updated TINKERPOP-3100:
---------------------------------------
Description:
Hi, we are currently upgrading to TinkerPop 3.7, and noticed that some of our
larger queries were taking much longer than expected to applyStrategies / lock.
[I've created an example project with a contrived complex traversal that
reproduces the
issue]([https://github.com/camfiander-sonrai/TinkerPopLockPerformanceRepro]).
I noticed that many of the children steps were getting locked more than once,
which shouldn't be necessary. I think the problem is
[here]([https://github.com/apache/tinkerpop/blob/3.7.2/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/DefaultTraversal.java#L333]).
`applyTraversalRecursively`, called from the traversal root, should apply the
`lock()` to all children, grandchildren, and so on. But each child also calls
`applyTraversalRecursively`, meaning the number of times a step is locked
scales with the depth of the traversal.
```sh
TinkerPop 3.5.3
Applied strategies in PT3.695S
TinkerPop 3.7.2
Applied strategies in PT15.079S
```
was:
Hi, we are currently upgrading to TinkerPop 3.7, and noticed that some of our
larger queries were taking much longer than expected to applyStrategies / lock.
[I've created an example project with a contrived complex traversal that
reproduces the
issue](https://github.com/camfiander-sonrai/TinkerPopLockPerformanceRepro).
I noticed that many of the children steps were getting locked more than once,
which shouldn't be necessary. I think the problem is
[here](https://github.com/apache/tinkerpop/blob/3.7.2/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/DefaultTraversal.java#L333).
`applyTraversalRecursively`, called from the traversal root, should apply the
`lock()` to all children, grandchildren, and so on. But each child also calls
`applyTraversalRecursively`, meaning the number of times a step is locked
scales with the depth of the traversal.
```sh
# TinkerPop 3.5.3
Applied strategies in PT3.695S
# TinkerPop 3.7.2
Applied strategies in PT15.079S
```
> Traversal.Admin.lock() has excessive recursion
> ----------------------------------------------
>
> Key: TINKERPOP-3100
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3100
> Project: TinkerPop
> Issue Type: Bug
> Components: console, process
> Affects Versions: 3.7.2
> Environment: M1 Macbook, 16GB RAM
> Reporter: Cameron Fiander
> Priority: Major
> Labels: performance
>
> Hi, we are currently upgrading to TinkerPop 3.7, and noticed that some of our
> larger queries were taking much longer than expected to applyStrategies /
> lock. [I've created an example project with a contrived complex traversal
> that reproduces the
> issue]([https://github.com/camfiander-sonrai/TinkerPopLockPerformanceRepro]).
> I noticed that many of the children steps were getting locked more than once,
> which shouldn't be necessary. I think the problem is
> [here]([https://github.com/apache/tinkerpop/blob/3.7.2/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/util/DefaultTraversal.java#L333]).
> `applyTraversalRecursively`, called from the traversal root, should apply
> the `lock()` to all children, grandchildren, and so on. But each child also
> calls `applyTraversalRecursively`, meaning the number of times a step is
> locked scales with the depth of the traversal.
> ```sh
> TinkerPop 3.5.3
> Applied strategies in PT3.695S
> TinkerPop 3.7.2
> Applied strategies in PT15.079S
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
