groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Building Groovy
Date Mon, 18 Dec 2017 00:01:39 GMT
Just came across this as an example where using Groovy 2.4.6 
invokedynamic seems to have been much slower than the older callsite 
caching mechanism: 
https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones 
(https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)

Quote:
"While Groovy has performance options that allow you to keep your code 
dynamically typed I never had good results with them. For Moqui 
Framework using the Indy compiler and runtime (for Java invokedynamic) 
actually made it significantly slower!
The best option for code that needs to run fast is the @CompileStatic 
annotation. When you apply this annotation you can't use Groovy features 
that depend on dynamic typing, but fortunately most of the more useful 
features still work just fine."

I can totally understand the pull to get rid of large, old code parts - 
but if this holds for more projects, I expect it will not go down well 
with (dynamic) Groovy users...
mg


On 21.11.2017 17:38, Jochen Theodorou wrote:
>
>
> Am 21.11.2017 um 08:28 schrieb Paul King:
>> The "double" build is because of indy vs non-indy (one wipes out the 
>> other) because of some assumptions that keep other parts of the build 
>> simple. Could no doubt be streamlined given some TLC.
>>
>> Last I checked there were different performance characteristics 
>> between indy/non-indy. We haven't gotten around to working out the 
>> best path forward yet that will give us one set of jars without 
>> losing performance in some scenarios. Again, just needs some time 
>> dedicated to it.
>
> I don't see the old callsite caching still working properly in a Java9 
> world, so it is time to cut loose
>
> bye Jochen
>


Mime
View raw message