[
https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622660#comment-15622660
]
ASF GitHub Bot commented on TINKERPOP-887:
------------------------------------------
Github user okram commented on the issue:
https://github.com/apache/tinkerpop/pull/470
I ran a benchmark:
**BRYN'S BRANCH**
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin>
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>5.142378699999999
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>778.8892011
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>1234.6360252
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>2.2864299399999997
gremlin> clock(100){ h.V().count() }
==>0.01190773
```
**MASTER BRANCH**
```
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.io(gryo()).readGraph('data/grateful-dead.kryo')
==>null
gremlin> h = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin> g = graph.traversal().withoutStrategies(LazyBarrierStrategy.class)
==>graphtraversalsource[tinkergraph[vertices:808 edges:8049], standard]
gremlin>
gremlin> clock(100){ h.V().out().out().out().toSet() }
==>3.2528534
gremlin> clock(20){ g.V().out().out().out().toSet() }
==>701.7937965499999
gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() }
==>1374.86072635
gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() }
==>2.4810170499999997
gremlin> clock(100){ h.V().count() }
==>0.01866702
```
The reason for the `withoutStrategies(LazyBarrierStrategy)` is that I
wanted to test lots and lots of results and thus, test the cost of the added
`try/catch`-block. I guess the costs are neglible (?? what do others think ??).
Also, @bryncooke, can you provide an example of master/ vs. your branch of
when its good to get a `NoSuchElementException`? When I do:
```
gremlin> g.V().out().values('age').next()
java.util.NoSuchElementException
Type ':help' or ':h' for help.
Display stack trace? [yN]y
java.util.NoSuchElementException
at
org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:194)
...
```
...all I learn is that the traversal `next()` method couldn't find
anything. But that is obvious. When is it NOT obvious?
> FastNoSuchElementException hides stack trace in client code
> -----------------------------------------------------------
>
> Key: TINKERPOP-887
> URL: https://issues.apache.org/jira/browse/TINKERPOP-887
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.0.2-incubating
> Reporter: Bryn Cooke
> Assignee: Marko A. Rodriguez
> Priority: Minor
>
> I wrote some code that incorrectly assumed that a Gremlin query would return
> an element, but it didn't. The surprise was that I got no stack trace and
> therefore had no idea where in *my* code I had introduced the error.
> I haven't looked in detail at the TP code, so what comes next is speculation:
> If FastNoSuchElementException is being used in truly exceptional
> circumstances then why is a singleton is used over a normal exception with
> stack trace? It could just as easily be converted to a normal exception.
> If FastNoSuchElementException is being used for control flow then probably it
> shouldn't. Code should check hasNext rather than trying for next and dealing
> with an exceptional result. I'm not sure what the current state of things are
> in the JVM but at least in the past try catch blocks would inhibit
> optimization even without stack traces so this type of code was considered an
> antipattern.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
