groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject [No Subject]
Date Tue, 05 Jul 2016 08:05:59 GMT
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