Stream g.V(v).outE() results

[li-boxuan]

See https://lists.lfaidata.foundation/g/janusgraph-users/topic/88677270#6380

g.E().hasNext() is fast, and that’s because the results are streamed. On the other hand, g.V(v0).outE().hasNext() is slow if vertex v0 has a huge amount of incident edges, and that’s because the results, in this case, are not streamed. It definitely needs some investigation, but usually, it’s not a big problem because people don’t expect a large number of incident edges attached to a node.

[rngcntr]

I did not see any further response on the mailing list about the usage of limit(). Does it mitigate the issue to use limit() right before hasNext()?

[nguyenm100]

I did not see any further response on the mailing list about the usage of limit(). Does it mitigate the issue to use limit() right before hasNext()?

think you mean range(). sure, that can be done but that can be done with virtually all calls and but the burden shifts to the caller. given that streaming is already a concept used elsewhere in the system, why not make it available everywhere for the benefit of all callers.

[rngcntr]

My point was that if this solves the issue, it would be an easy fix to deploy a strategy which replaces hasNext() by limit(1).hasNext() in every traversal.

[nguyenm100]

My point was that if this solves the issue, it would be an easy fix to deploy a strategy which replaces hasNext() by limit(1).hasNext() in every traversal.

again, I think you mean range(0,1), range(1,2), etc. unless limit() is stateful?

[li-boxuan]

limit is not stateful. @rngcntr limit(1).hasNext() is very handy when the user just wants to know the existence, but the original problem as stated in the mailing list is that the user wants to iterate over all results as a stream.

[rngcntr]

Alright, got it. Thanks for the clarification!