[jira] [Comment Edited] (TINKERPOP-1444) Benchmark bytecode->Traversal creation and implement GremlinServer cache if necessary.

["Marko A. Rodriguez (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15493722#comment-15493722 ] 

Marko A. Rodriguez edited comment on TINKERPOP-1444 at 9/15/16 3:56 PM:
------------------------------------------------------------------------

This is the problem. Once a traversal has been built, the binding values are "solidified." Meaning, you CAN'T have a "generic traversal" whose arguments are supplied later. So, while you can {{clone()}} a traversal and re-use it, you can't change its parameterization because its already been compiled and during compilation, many of those parameters were used to determine how it would be compiled. Thus, the best "prepared statement" we have is {{Bytecode}} which is the closest you can get to a traversal instance and still mutate parameters. Previous to {{Bytecode}} the closest thing you had was a Groovy {{String}}. This is analogous to Java/JIT/etc.


was (Author: okram):
This is the problem. Once a traversal has been built, the binding values are "solidified." Meaning, you can have a "generic traversal" whose arguments are supplied later. So, while you can {{clone()}} a traversal and re-use it, you can't change its parameterization because its already been compiled and during compilation, many of those parameters were used to determine how it would be compiled. Thus, our "prepared statement" is simply {{Bytecode}} which is the closest you can get to a traversal instance and still mutate parameters. Previous to {{Bytecode}} the closest thing you had was a Groovy {{String}}.

> Benchmark bytecode->Traversal creation and implement GremlinServer cache if necessary.
> --------------------------------------------------------------------------------------
>
>                 Key: TINKERPOP-1444
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1444
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: benchmark, language-variant, process, server
>    Affects Versions: 3.2.2
>            Reporter: Marko A. Rodriguez
>
> Right now, when you send {{Bytecode}} to GremlinServer, it will convert the bytecode to a traversal either via Java reflection (Gremlin-Java) or script engine evaluation (e.g. Gremlin-Groovy, Gremlin-Python).
> We should see how fast the process is to go from Bytecode to Traversal and if its "slow" we should create a {{Map<Bytecode,Traversal>}}-cache in GremlinServer.
> The reasons it may be "slow" are:
> 1. {{JavaTranslator}} uses Java reflection to translate bytecode to traversal and that code is a little "thick" and either should be optimized (if possible) or, instead, bytecode/traversal translations should be cached.
> 2. {{Groovy/PythonTranslator}} uses string construction to generate a script from the bytecode. While that script may be cached, it would be good if we have a cache prior to that which simply just grabs the traversal from a bytecode cache.
> I think that we will definitely want a cache as it should make things fast, but it will be good to know how much faster prior to diving into such work.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)