[
https://issues.apache.org/jira/browse/TINKERPOP3-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011053#comment-15011053
]
stephen mallette commented on TINKERPOP3-604:
---------------------------------------------
I looked into this one a little bit the other day. We can add this without it
being a breaking change, but TinkerGraph/Neo4j don't seem to be able to take
advantage of it as-is. For TinkerGraph, i guess we'd need a secondary indexing
of the edges for it to be good and i don't think Neo4j has a way to speed it up
at all.
I guess the problem is that the default implementation of this new method would
fall back to iteration until the id is found which is possibly costlier than
doing a lookup by direction/label/iterate depending on the provider. As this
was an OLAP related issue, perhaps it's not an issue that
TinkerGraph/Neo4j/others need to worry about?
> DetachedEdge.attach(Vertex) is too slow.
> ----------------------------------------
>
> Key: TINKERPOP3-604
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-604
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: io
> Affects Versions: 3.0.2-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
>
> We need a new method on Vertex.
> {code:java}
> Vertex.edges(Object... ids)
> {code}
> Right now to attach, we do a linear scan of all edges to find the edge with
> the right id. If the edges are already indexed by (e.g. HashMap) by the
> vendor, then O(1) can be achieved.
> This is killing us in OLAP where we have to read vertices from disk and those
> vertices can contain thousands (if not millions) of edges. And then if the
> graph engine uses "out of core" to cache data, we are hit again with the
> attachment cost.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
