groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re:
Date Tue, 05 Jul 2016 11:52:18 GMT

On 05.07.2016 10:05, Thibault Kruse 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:

It is no new problem, it is, as Cedric said, a "terrible design 
decision"... done somewhen long ago... 10+ years ago. Back then it made 
more sense, because back then the MetaClass was always doing the actual 
invocation. With callsite caching this changed.... but the time back 
then was not used to correct that mistake.

> 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?

that is not easy to answer... the compiler is in Java, but transforms 
might be in Groovy, so there is potential, even though it is not much. 
Then the runtime core is in Java, but we are doing dynamic invocations 
inside, from Java code at some points.

No, in total I must say it depends on your use case. We have some paths, 
that may suffer from that and many paths that do not. if you for example 
test against a builder, then you would of course get the problem. Method 
invocations for example do not have the problem as much... properties 
tend to have problems, but if you want to write a benchmark, you cannot 
use a local variable or field in the same class. You have to access the 
property of something that is not "this". And then you should notice 
terrible performance, because afaik we do not cache property access at 
all in non-indy.

bye Jochen

View raw message