[ https://issues.apache.org/jira/browse/TINKERPOP-887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15622949#comment-15622949 ]
ASF GitHub Bot commented on TINKERPOP-887: ------------------------------------------ Github user BrynCooke commented on the issue: https://github.com/apache/tinkerpop/pull/470 Exactly. It's currently a huge pain to figure out where things have gone wrong. Without this patch I have to divide and conquer my code every time I hit a FastNoSuchElementException. There is no cost to a try/catch block. The construction of the regular NoSuchElementException is expensive, but should only be thrown on the top level traversal. I actually found no significant difference between branches in terms of performance. Mine ``` 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> clock(100){ h.V().out().out().out().toSet() } ==>3.33155785 gremlin> clock(20){ g.V().out().out().out().toSet() } ==>520.2727724499999 gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() } ==>903.5254189999999 gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() } ==>1.8392006699999999 gremlin> clock(100){ h.V().count() } ==>0.0069826 gremlin> ``` Master ``` 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> clock(100){ h.V().out().out().out().toSet() } ==>3.59260972 gremlin> clock(20){ g.V().out().out().out().toSet() } ==>519.7500263 gremlin> clock(20){ g.V().out().flatMap(out()).flatMap(out()).toSet() } ==>907.32923195 gremlin> clock(100){ g.V().repeat(out()).times(3).toSet() } ==>1.76869779 gremlin> clock(100){ h.V().count() } ==>0.006985369999999999 gremlin> ``` > 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)