groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: Building Groovy
Date Tue, 19 Dec 2017 17:23:33 GMT
On Tue, Dec 19, 2017 at 11:21 AM, MG <> wrote:

> Hmmm, I don't know if Paul has some comeback, but to me you make a very
> convincing point...

I agree with earlier comments in particular from Jochen and C├ędric. I also
suspect that JDK 9 issues may force us down the indy only path at some
point not too far away and I think we just have to keep optimising the
common cases in the meantime using some benchmarking tests perhaps to guide
efforts - just hard to find the time to tackle that right now.

Cheers, Paul.

> In that case the best way forward to me seems to be to
> 1) Ask non-@CompileStatic Groovy users who can afford the time to switch
> to the invoke dynamic variety of the Groovy jars and report back on
> performance issues (tests that run much slower, etc)
> 2) Add a clearly visible message to the Groovy distribution download
> section, Maven/etc URL spots that Groovy 3.0 will be invoke dynamic only,
> and again ask for people to use indy now & give feedback if code seems to
> be unusally slow
> 3) Start a competition who can come up with the most unexpectedly worst
> performing piece of Groovy indy code... ;-)
> (To be quite honest, I am wondering myself how invoke dynamic can be
> slower than the older, homebrewn approach, even if that is highly optimized
> - it seems to me like it should be a bit like a software renderer going up
> against a GPU...)
> Cheers,
> mg
> On 18.12.2017 15:54, Jochen Theodorou wrote:
>> On 18.12.2017 01:01, MG wrote:
>>> 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:
>>> /how-make-groovy-fast-java-david-e-jones (
>>> w-to-make-groovy-as-fast-as-java)
>> It is a chicken-egg problem. We still need to optimize indy in some
>> areas. But this does not happen if no users care to give detailed reports
>> which we can base optimizations on. They on the other hand simply switch to
>> static compilation or old callsite caching then. So in the end there is no
>> optimization, because optimizations tend to inflate and complicate code.
>> And for the old callsite caching there is another part... I highly doubt
>> it is still well working with JDK9. Worse, I do not see how this can be
>> made work efficiently under JDK9. The preferred way in JDK9 is
>> invokedynamic after all. And while they (JDK developers) tend to increase
>> the capabilities of invokedynamic, it is the opposite story for reflection
>> (deep reflection, callsite sensitive rights made even worse through
>> modules, ...)
>> So frankly I do not see much of a future for the old callsite caching
>> bye Jochen

View raw message