[
https://issues.apache.org/jira/browse/TINKERPOP-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18003889#comment-18003889
]
ASF GitHub Bot commented on TINKERPOP-3100:
-------------------------------------------
Cole-Greer commented on PR #3152:
URL: https://github.com/apache/tinkerpop/pull/3152#issuecomment-3050234923
VOTE +1 (pending actions passing)
> 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: Critical
> 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.
> {code:java}
> # TinkerPop 3.5.3
> Applied strategies in PT3.695S
> # TinkerPop 3.7.2
> Applied strategies in PT15.079S{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
