groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <>
Subject Re: Help with pitching Groovy and Grails
Date Fri, 24 Feb 2017 09:04:11 GMT
----- Mail original -----
> De: "Jochen Theodorou" <>
> À:
> Envoyé: Mercredi 22 Février 2017 22:49:01
> Objet: Re: Help with pitching Groovy and Grails

> On 21.02.2017 22:51, Raviteja Lokineni wrote:
>> Hi Devs,
>> I was trying to pitch using Grails for one of our projects and the
>> discussions always ended up with "using reflections in JVM is slow
>> period". I am not knowledgeable to defend the internals of either Groovy
>> or Grails, need some help on this topic.
>> The only selling point that they identified was GORM.
>> I thought this might be the time to ask the developer community. I am
>> trying to gather some points on using Grails over a Spring boot application.
>> Also, can anyone help me understand how Groovy runtime optimizations are
>> applied on a high level and if it will affect the runtime performance.
> don´t forget in Grails you have a very thin Groovy layer over Java code.
> That little Groovy makes a big difference in the usage, but not in the
> performance part. And depending on what you do Groovy can be pretty fast
> (Java 10s, Groovy 15s for example). That might be related to Groovy
> actually not using Reflection where possible... well, of course I should
> also mention that for a example a method call using reflection use to be
> like factor 30 slower compared with a direct method call using Java. But
> that is no longer true for a long time. 

yes, 30x was a long long time ago, i think before 1.4.2.
The last time the reflection code was touched for speed update was during the Java 7 timeframe.

> And then in Groovy we use runtime code generation to avoid Reflection and optionally
you could
> also use the indy port, which is based on invokedynamic (the same one
> that is used for method calls for lambdas) which can be pretty fast. And
> if that is not enough, you can still use the static compiler to be
> around the same level as Java.

Technically, invokedynamic is used from creating the lambda not for calling it, because after
creation it's more like a plain reference on an object that implement a functional interface,
so it can be called like a plain old interface. There has been a prototype to use invokedynamic
to call the lambda but performance was identical to an interface call so it was not integrated
because invokedynamic makes the startup a little slower (like reflection does).

In the jdk 9, invokedynamic is used when you do a concatenation with + because invokedynamic
is faster that using a chain of plain old Java calls to StringBuilder.append().

> bye Jochen


View raw message