Using as() step is slowing down Gremlin Query dramatically

[cmilowka]

Using as() step is slowing down performance of the Gremlin Query with some combinations
specifically when Filter Segment is used, for example:

• around 500 milliseconds: g.V().and( __.properties("amount"))
• around 2 seconds: g.V().as("MARKER").and( __.properties("amount"))
  Timing was measured by dedicated procedure, and is similar to the one reported by profile() step as samples below.

We have the same experience on our commercial JanusGraph system with big data, where performance of some similar queries with the Reference Markers are 5 x times slower than without it.

Interestingly, adding barrier(2500) step is able to improve performance, e.g.

• around 500ms: g.V().as("MARKER").barrier(2500).and( __.properties("amount"))

Steps to reproduce using popular samples from JanusGraph documentation

graph = JanusGraphFactory.open("inmemory")
mgmt = graph.openManagement()
timestamp = mgmt.makePropertyKey("timestamp").dataType(Integer.class).make()
amount = mgmt.makePropertyKey("amount").dataType(Integer.class).cardinality(Cardinality.LIST).make()
mgmt.buildPropertyIndex(amount, 'amountByTime', Order.desc, timestamp)
mgmt.commit()

for (int ii=0; ii < 100000; ii++) { bob = graph.addVertex();  bob.property("amount", 100, "timestamp", 1600000000);  bob.property("amount", 200, "timestamp", 1500000000);	bob.property("amount", -150, "timestamp", 1550000000); }	

g = graph.traversal()

• around 500 milliseconds: g.V().and( __.properties("amount").has("timestamp",P.eq(1600000000))).count().profile()
• around 2 seconds: g.V().as("MARKER").and( __.properties("amount").has("timestamp",P.eq(1600000000))).count().profile()

Similar results are also for just simplified queries, however the difference is not that drastic in memory DB, however bigger in reality

• around 80ms: g.V().count().profile()
• around 90ms: g.V().as("MARKER").count().profile()