2017-12-19 2:21 GMT+01:00 MG <mg...@arscreat.com>: > Hmmm, I don't know if Paul has some comeback, but to me you make a very > convincing point... > 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) >
This has been the case for years now, and almost nobody uses the invokedynamic version. It's not just the fault of the users: when you have a dependency on a library that is built to use the old call site caching version, it's just not possible to "switch it to indy". > 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 > I disagree. 99% of our users don't even know what call site caching is. They don't know what invokedynamic means, and they don't have to. It's an internal implementation detail. What they care, on the other hand, is performance. So "is it slow? yes -> report a bug". No one has to care about the implementation detail, unless you're a language designer. > 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...) > Again, I don't think optimizing the worst case is what we need to do. We need to optimize the most common cases. If there are edge cases worth optimizing, we can try, but we shouldn't compromise on the other cases for a corner one. > > 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 >> >> >
