On 23.06.2016 15:50, Winnebeck, Jason wrote: [...]
As for switching purely to indy, I've heard a lot of issues on this list where people say it's slower, or at least the same. Has that changed now?
the problem is that the work on this part of the JDK is still ongoing. Each test has to be done with a multitude of java versions and with each version new. That is due to JDK8 making extensive use of invokedynamic and MethodHandles for lambdas. JDK9 will even use it to speed up String concatenation. So while in JDK7 indy was kind of a pet project with a native code based implementation first, JDK8 caused the implementation to be changed completely to internally runtime generated classes, which had a lot of quirks in the beginning and a lot of optimization work to be done in hotspot. And since the backports to JDK7 have been done sometimes a bit half hearted (like introducing new bugs) JDK7 and JDK8 are completely different stories. But even in JDK8 things have been improved over time a lot and still are.
If performance is the same it is good enough for me. If it is slower, it might be that the next version of the JDK improves here. I do also think we still have some air in our invokedynamic based implementation to improve some things
It's on my long list to benchmark our application with indy groovy but as we use compile static almost exclusively so it’s not a high priority, but we use dynamic exclusively when producing or consuming web services where it's nice to use things like XmlSlurper that don't work with compile static and so indy is still of interest in our project.
I really wonder if there will be much performance difference in the usage of the XmlSlurper. If there are negative effects, it would be interesting to have your benchmark and trying to improve on it. As I said, I do think we can still make things faster on the invokedynamic side.
bye Jochen
