You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/03/24 19:55:41 UTC

[jira] [Commented] (TINKERPOP-1095) Create a custom ScriptContext

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

ASF GitHub Bot commented on TINKERPOP-1095:
-------------------------------------------

GitHub user spmallette opened a pull request:

    https://github.com/apache/tinkerpop/pull/584

    TINKERPOP-1095 Gremlin Server performance improvement with SimpleScriptContext

    https://issues.apache.org/jira/browse/TINKERPOP-1095
    
    The issue is about creating a custom `ScriptContext`  for improved usability purposes but it's since morphed to an important performance improvement for the `GremlinScriptEngine` and thus also Gremlin Server.  The change uses the custom `ScriptContext`, named `GremlinScriptContext`, to  prevent usage of the `SimpleScriptContext` which creates `ByteBuffer` instances on every call to `eval()` and those instances were never used making them immediately available to GC. 
    
    For Gremlin Server it seems that it has been cycling GC way more than it should have been. Here's GC activity before my changes:
     
    ![GC Before](https://issues.apache.org/jira/secure/attachment/12860396/gc-before.png)
    
    and GC activity after my changes:
    
    ![GC After](https://issues.apache.org/jira/secure/attachment/12860395/gc-after.png)
    
    Obviously the amount of memory allocated was greatly reduced in the process. The number of `byte[]` instances was allocated held 2.91 GB prior to the changes:
    
    ![Allocation Before](https://issues.apache.org/jira/secure/attachment/12860398/allocations-before.png)
    
    and for the same workload after the changes just 638 MB:
    
    ![Allocation After](https://issues.apache.org/jira/secure/attachment/12860397/allocations-after.png)
    
    I can't think of anything wrong with replacing `SimpleScriptContext` and all the tests seem fine as a result with Docker so - VOTE +1


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/apache/tinkerpop TINKERPOP-1095

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/tinkerpop/pull/584.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #584
    
----
commit 48daf8d25fcf3abb9d2a3c307e65ec6613595959
Author: Stephen Mallette <sp...@genoprime.com>
Date:   2017-03-24T16:23:46Z

    TINKERPOP-1095 Added a custom ScriptContext
    
    Used the custom ScriptContext, GremlinScriptContext, to  prevent usage of the SimpleScriptContext which creates unnecessary ByteBuffer instances on every call to eval().

----


> Create a custom ScriptContext
> -----------------------------
>
>                 Key: TINKERPOP-1095
>                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1095
>             Project: TinkerPop
>          Issue Type: Improvement
>          Components: groovy
>    Affects Versions: 3.1.0-incubating
>            Reporter: stephen mallette
>            Assignee: stephen mallette
>         Attachments: allocations-after.png, allocations-before.png, gc-after.png, gc-before.png
>
>
> The current {{ScriptContext}} in use with the {{ScriptEngine}} is the {{SimpleScriptContext}}.  It doesnt' allow for additional scopes which might be useful when dealing with the {{ScriptEnginePluginAcceptor}} which allows plugins to inject "global" bindings into the a {{ScriptEngine}} instance (e.g. the "hdfs" object with the hadoop plugin).
> We currently inject this into the {{GLOBAL_SCOPE}} of the {{ScriptEngine}} which at the moment doesn't seem to conflict with anything, but I wonder if more separation is required.
> Another alternative would be to manage these types of "globals" with new methods on the {{DependencyManager}} interface.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)