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
