Reputation: 12191
I have some integration tests using TinkerGraph (in memory) which take 10-15 seconds each to finish. From monitoring, using VisualVM, I have figured out that the main cause of delay is due to TraversalHelper.getLabels()
and TraversalHelper.getTraversals()
methods.
I was expecting TinkerGraph as it is an in-memory to be blazing fast but it could be that I am doing something wrong or there is indeed some performance issue. My other tests are less than 200ms.. Any help is appreciated!
Here is a query that takes 5+ seconds to create 51 vertices with about 4-5 properties each interconnected through 89 edges:
UPDATE: Performance in my tests was improved from ~40s to ~6s for in-memory tests and from 2mins to under 1min using DSE after using the newly deployed 3.2.5-SNAPSHOT and 3.3.0-SNAPSHOT (from http://repository.apache.org/snapshots/). For more details you can have a look here: https://issues.apache.org/jira/browse/TINKERPOP-1642. I would like to say a big Thanks to stephen mallette for his quick and precise action that yielded great performance improvement not only for the in-memory gremlin traversals but also all the other disk-based graph technologies that use gremlin on top of them.
Upvotes: 1
Views: 289
Reputation: 46226
That's a pretty massive piece of Gremlin. I'm honestly not sure what to expect in terms of performance on a hunk of Gremlin with 350+ chained statements.
I would offer a few bits of advice. Trying to do all that work in one single line of Gremlin creates code that is hard to read and difficult to maintain. You likely wouldn't try to write your non-Gremlin code that way (no matter what language you are working in), so it's probably good to consider your standard programming techniques when writing Gremlin.
While I'm not sure what the performance should be on this large a hunk of Gremlin, I do know that if you split that statement down into smaller more manageable bits, creating 51 vertices and 89 edges should not take 5+ seconds to run. I don't know what to attribute that difference to offhand, but you are creating a fair amount of overhead for yourself in the traversal with all those step labels, which perhaps explains the endless calls to getLabels()
that you mentioned in your question.
Update: See discussion below
Upvotes: 3