On Tue, Dec 19, 2017 at 11:21 AM, MG <[email protected]> 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: https://www.linkedin.com/pulse >>> /how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/ho >>> 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 >> >> >
