I'm not really answering your question, but, AFAIK, Groovy is not the only JVM language to use exceptions for control flow. Maybe it is using too many of them, too often, I don't know. Anyway, not filling the stack trace can help a lot with exception performance, so that may be a cheap solution.
On 5 July 2016 at 10:05, Thibault Kruse <tibokr...@googlemail.com> wrote: > Hi, > > (I tried sending this mail before, failed so far) > > This is about using @CompileStatic inside core Groovy code. > > The analysis of gradle plugins by Cedric revealed a potential > problem with dynamic Groovy: > > http://melix.github.io/blog/2016/05/gradle-kotlin.html > "I think at some point, someone made a terrible design decision in > Groovy. I don’t know who it was, but the idea was to rely on > exceptions to control the flow of resolution of properties. This means > that when a property is missing, typically in a closure, an exception > is thrown. When a method is not found, an exception is thrown. When a > property is not found, an exception is thrown. That seemed to be a > good idea, because in the end, you want to provide the user with an > error, but in practice, this is catastrophic, because Groovy can > capture those exceptions. Typically, in a delegation chain (nested > closures), a containing closure or class can actually have this > property defined, or implement property missing/method missing. Now, > re-think a second about the "simple" example of Gradle build above: > how do you now where to look up for message, top, signature, …? Now > you know: f* exceptions are thrown, stack traces are filled, and > eventually captured because some composite dynamic object finally > wants to answer the message… In practice, for some builds I have > profiled, it was tens of thousands of exceptions being thrown and > stack traces filled for nothing. And that has a terrible impact on > performance." > > Now I am wondering, since parts of Groovy itself are written in > Groovy, and @CompileStatic is not much used in side Groovy itself, > does core Groovy suffer from performance issues due to the same reasons > as well? >
