[
https://issues.apache.org/jira/browse/TINKERPOP-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15922929#comment-15922929
]
stephen mallette commented on TINKERPOP-1642:
---------------------------------------------
First, as a quick update as there are some folks keeping an eye on this issue,
the latest TINKERPOP-1642 branch is significantly faster at this point than
what is currently performing in tp32. Specifically, long chained mutating
traversals run more on par with the speed of the same mutations broken into
lots of smaller individual traversals. As a side-effect we should also see
improvements with traversals that have use of labels/select. There has been
some improvement on {{g.addE()}} and the speed of {{g.addV()}} with properties
has about doubled at this point as well. All that said, there is still room for
improvement as the traversal API still lags behind the structure API (just by
much less than before). I'm not sure what our goal is for this ticket, but it
would be nice if we could achieve a reasonable parity between them.
As an update on current analysis, dropping all unnecessary strategies improves
things quiet significantly in comparison to the current
[head|https://github.com/apache/tinkerpop/commit/1fac7cf3c59b874ca4acb950030b1cd98410a639]
of TINKERPOP-1642:
* {{g.addE()}} - 2x faster
* {{g.addV()}} - not much change - perhaps that makes sense since {{addV()}}
with a bunch of properties would still just yield a single {{AddVertex}} step
to iterate strategies over
* long chained traversals improved by a factor of 6x when adding vertices/edges
and not much change when just adding vertices
Ultimately it seems like the improvements related to not applying strategies
seem to mostly help with adding edges.
based on these improvements it seems wise to consider TINKERPOP-1366 or other
related work to drop out strategies for a traversal that don't need to be
executed base on the steps present (e.g. why execute {{ProfileStrategy}} if
{{profile()}} was never called. Or is there some way to detect a traversal with
just mutating steps and then do smart strategy application that way?
> Improve performance of mutating traversals
> ------------------------------------------
>
> Key: TINKERPOP-1642
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1642
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.2.4
> Reporter: stephen mallette
> Assignee: stephen mallette
> Priority: Critical
>
> Make an attempt improve performance of mutating traversals. Some general
> goals for this ticket should be to:
> 1. Improve performance parity of structure and process methods for modifying
> the graph - structure is pretty far ahead.
> 2. Improve the speed of large chained mutating traversals - see
> http://stackoverflow.com/q/41926409/1831717
> 3. Determine ways to make these performance improvements in {{gremlin-core}}
> so that they may benefit all {{Graph}} implementations
> 4. Improve the speed of TinkerGraph specifically if possible as it is used
> for subgraphing functions in many cases and ends up being useful regardless
> of the graph implementation ultimately used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
