Hi Jonny, I pinned this Grails ticket: https://github.com/apache/grails-core/issues/15293
The user put together a benchmark repo with both a Grails 6 (groovy3) and Grails 7 (groovy 4 with indy left enabled). We do not have a Groovy 5 version working yet - there are still compile errors (as we have time we have opened tickets to address and the groovy devs have been quick to fix them). On a more personal note, I have a substantial Grails application in my corporate job. While it uses most of the features of Grails, it also has a large backend processing presence. This backend is more groovy than Grails so performance impacts are very noticeable. I am happy to test or help with any effort to make indy fast. The performance impacts are significant enough that I too have had to disable indy when adopting Groovy 4. -James On Wed, Dec 31, 2025 at 4:39 PM Jonny <[email protected]> wrote: > 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 >> >
