Hey Dylan, Huh -- that is a neat use case.
If your Gremlin is generated by code, you can rest easy knowing that the TraversalStrategies will optimize it at compilation-time. Very cool, Marko. http://markorodriguez.com On May 6, 2015, at 5:46 AM, Dylan Millikin <[email protected]> wrote: > 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 >>
