groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Stalla <alessiosta...@gmail.com>
Subject Re:
Date Tue, 05 Jul 2016 08:23:26 GMT
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 <tibokruse@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?
>

Mime
View raw message