I've only been on the edge of the discussion around performance on Groovy 4 & 5. Digging through some of the threads above has left me with a few thoughts.
First, I would caution anyone who hopes that moving to plain Java is necessarily going to improve the problem of "major language upgrades sometimes require substantial rewrites." Java's got its own release train, and while they do play the conservative "last mover" advantage as much as they can, it's not like the problem of upgrades goes away. That said, it's worth considering whether we might be able to provide some help to folks upgrading to avoid common performance gotchas. I know there are OpenRewrite recipes for Gradle upgrades. If we knew where likely pitfalls were, maybe we could provide something similar for Groovy? We'd need to know what things to target, though, which brings me to a more specific, actionable point: In one case <https://lists.apache.org/thread/q257zbtvm0jgnr5gqojfcpphlfpoos94>, after the user switched from doing their performance testing in debug mode to a production mode (runWar), the performance gap closed significantly (about 200ms slower for rendering a large stress test page, rather than triple the time). I know that Jochen has some thoughts on improving the performance of InvokeDynamic, which probably could help address things in a "root cause" way. That said, Gianluca's experience makes me wonder if there are some other low-hanging fruit that would help address the problem for big Grails apps. I know that it was mentioned somewhere that someone provided a sample application that demonstrates some issues, but I haven't been able to find it on a second pass. Do you have that example app handy, mg? Best, Jonny On Wed, Dec 31, 2025 at 1:52 PM MG <[email protected]> wrote: > Hi .+, > > I just saw this 2 week old comment on Grails 7/Groovy 4 INDY performance > (bold by me; > https://github.com/apache/grails-core/issues/15293#issuecomment-3676632134 > ): > > Thanks for raising this issue, we also hit the problem of a massive > performance hit using Grails 7/Groovy 4 on our large codebase, and were > partially rectifying that by converting more of our code to either > @CompileStatic or just to Java. *Every Groovy upgrade has given us > challenges with compile performance, runtime performance, language > behaviour changes* etc *so our long term goal is to switch to pure Java* > which I believe will be more stable and perform better. The tip of > disabling indy has been very helpful because it's allowed us to get over > the issue for now and in fact due to the rework we've done, our app is > faster than before! > > > Even though in our large codebase we were able to successfully steer > around this issue by going partially @CompileStatic, I feel like Groovy 5 > being INDY-only could pose more of a risk for the future of the Groovy > language than previous changes, if more companies/orgs with larger Groovy > applications/frameworks decide to switch to Java. > > => > > 1. *To fix the root cause of performance drop-off:* *Could a Grails > application be used to try out the INDY performance improvements Jochen > suggested in August* ? > 1. (As I said before, our code needs to be closed source and we > therefore alas cannot supply the needed test case.) > 2. *To make switching to new Groovy major versions faster/easier > under @CompileStatic/@TypeChecked:* One of the main sources of > problems when doing the switch to a new major Groovy version we encounter, > is that Groovy continues to be *ever more strict with regards to > generics arguments*. > 1. A non-negligible part of the work to get the two base modules of > our framework to compile under @CompileStatic was adding "as > List<SomeClass>" or similar to our code, to get Groovy to accept it. > 2. I know covariance in general is a complicated & intricate > problem, but can we instead find a Groovy solution here following "make > the > frequent case simple/fast, make the rare case correct", and instead of > being more strict*, do things like e.g. a List<ChildOfGoo> being > accepted as a List<Goo>* ? > 1. Some cases can of course be solved by using List<T extends > Goo>, but alas even this does not always work in more complex > generics > constructs. > 1. (In some cases it would help to keep the code > Groovy-compact, if Groovy had its own more compact syntax for the > List<? > extends Goo> variety, e.g. List<Goo*> (i.e. appending a "*" after > the type) > ...) > > > A Groovy Happy New Year to everyone, Cheers, > mg >
