Replies: 3 comments 3 replies
-
This is a remarkable difference indeed, for which I do not see an immediate explanation. It would be interesting to see the full unedited output of the .profile() for both queries. |
Beta Was this translation helpful? Give feedback.
-
No idea what is going on, just two things that catch my eye:
|
Beta Was this translation helpful? Give feedback.
-
Excellent find and it makes sense: starting the new traversals in the closure allows them to be parallelized! If you want you can make an issue of this in this github repo to keep the research you did available. Actually, JanusGraph (or upstream TinkerPop) could implement some
You did a great job answering this question yourself and you were a bit unlucky that your question did not draw the attention of the project committers who read this forum. I am not a committer myself, but I have a broad general knowledge and memory of JanusGraph and TinkerPop that I like to leverage to stimulate talented developers. |
Beta Was this translation helpful? Give feedback.
-
Hi all,
I have a query that has some starting point, traverses through the graph and saves all the edges on the way.
After that, for each edge, I want to know the parent of it's source and the parent of it's target. It looks like this:
As stated in the title, the
project
step is very slow. I tried to replace it with this followingmap
step:Otherwise, the query stays the same.
The performance difference is huge! The
map
step is appx. 50x faster then the equivalentproject
.Do you know why?
It does not seem straightforward as the lambda starts 2 new traversals and then do the same steps. I would expect the project step to be faster.
Additional info
Backend: I tried both hbase and berkeleyje, same result
RAM - 12 GB
CPU - 4 cores, but only one is used at 100%
config:
.profile() outputs
.map()
.project() (40x slower in this case)
Beta Was this translation helpful? Give feedback.
All reactions