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
