This is actually really cool for non-java users where inE().outV() and out().count() may be a byproduct of script building libraries.
On Wed, May 6, 2015 at 6:39 AM, Daniel Kuppitz <[email protected]> wrote: > Hey guys, > > we just wanted to let you know that Gremlin is getting smarter and smarter. > We added a new traversal optimizer strategy: AdjacentToIncidentStrategy > <https://issues.apache.org/jira/browse/TINKERPOP3-654> (previously called > HalfStepTraversalStrategy). > > *What does it do?* > > It looks for typical patterns / step sequences in traversals that involve a > significant performance overhead (especially in OLAP), and replaces them > with "shorter" alternatives. > > *A few examples:* > > OriginalOptimizedg.V().out().count()g.V().outE().count() > g.V().in().limit(3).count()g.V().inE().limit(3).count() > g.V().values("name").count()g.V().properties("name").count() > g.V().has(__.out())g.V().has(__.outE())g.V().has(__.values()) > g.V().has(__.properties()) > > *What's next?* > > Now that we have AdjacentToIncidentStrategy, it's time to create an > IncidentToAdjacentStrategy. No kidding, the other way can be an > optimization too. Consider the following traversal: > > > g.V().outE().inV().has(__.out("friend")).has(__.outE("workedAt").inV().has("name", > "FooBar LLC")) > > > Believe me, I've seen a lot of queries like this in the past. But now, > after applying the two aforementioned strategies, we would end up with: > > g.V().out().has(__.outE("friend")).has(__.out("workedAt").has("name", > "FooBar LLC")) > > > Pretty cool, isn't it? > > Cheers, > Daniel >
