Hello,
There are two types of “programs” in Gremlin: Bytecode and Traversals.
Bytecode => Virtual machine instructions (like Java bytecode)
Traversals => Machine instructions (like Intel machine code)
The core of Gremlin’s compiler is its TraversalStrategies. A traversal strategy
works on a traversal-by-traversal level walking the traversal tree rewriting
sections of the traversal into (typically) more optimal forms.
void TraversalStrategy.apply(Traversal<S,E> traversal)
Working at the Traversal object level is important because the Gremlin language
steps (has(), out(), in(), etc.) don’t always map one-to-one with the machine
instructions (HasStep, VertexStep, VertexStep). Its better to work at the
machine-level because there are more nick-nack mutations one can do at that
level. However, as you can see, traversal strategies are “machine dependent.”
That is, they are tied to the Gremlin traversal machine implementation.
While there is currently only one Gremlin virtual machine (Gremlin-Java
machine), there are many Gremlin language variants — Gremlin-Java, -Groovy,
-Python, SQL-Gremlin, SPARQL-Gremlin, etc. When these languages communicate
with a/the Gremlin traversal machine, they communicate via Gremlin bytecode.
Now, it is possible to optimize bytecode. In principle, we can do “client side”
optimizations on the bytecode prior to sending it to the Gremlin traversal
machine for execution. Why would we want do this?
1. We can reduce the amount of work (clock cycles) required of “the
server” which would ultimately do the TraversalStrategy optimization.
2. We can have optimizations that are machine independent and thus, can
be useful against any Gremlin traversal machine implementation.
3. While the server is “streaming in” the Bytecode, it can also
optimize the bytecode prior to applying TraversalStrategy optimizations.
[Gremlin-Java Traversal Machine] <== network connection ==> [Gremlin-XXX
Language Variant]
* pre-process bytecode * pre-process
bytecode
before translating to traversal before sending
over network
* apply traversal strategies
* execute traversal
What would Bytecode strategies look like? Here is an idea:
void TraversalStrategy.apply(Bytecode bytecode)
Lets look at a simple strategy. IdentityRemoveStrategy will turn traversals of
the form g.V().identity().as(“a”).identity() into g.V().as(“a”). Here is this
strategy written in both Java and Python:
https://gist.github.com/okram/7bb2512935f8955551f9e3f87623b488
<https://gist.github.com/okram/7bb2512935f8955551f9e3f87623b488>
Given that there (currently) is no Gremlin-Python traversal machine
implementation, __apply_traversal(traversal) does nothing. However, given that
there is a Gremlin-Python language variant, __apply_bytecode(traversal) does
something. Moreover, note that we already have IdentityRemovalStrategy in
Gremlin-Python, but, as you can see, it does nothing as (currently) strategies
only operate on traversals.
https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/process/strategies.py#L117-L119
<https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/process/strategies.py#L117-L119>
AS A SIDE: The reason strategies exists in Gremlin-Python is so that users can
do stuff like:
https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L80-L98
<https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/tests/driver/test_driver_remote_connection.py#L80-L98>
Anywho, so there you have it. I’ve made a ticket:
https://issues.apache.org/jira/browse/TINKERPOP-1501
<https://issues.apache.org/jira/browse/TINKERPOP-1501>
You thoughts on the idea are more than appreciated.
Take care,
Marko.
http://markorodriguez.com
