Re: Looming Groovy 5 INDY-only Performance Problem

https://github.com/apache/grails-core/issues/15293 has been updated two two 100MB indy logs from the sample application.  One during application startup and one while running the performance test. 

https://github.com/apache/grails-core/issues/15293#issuecomment-3704230195

And also some automated analysis of those log files (sorry if this is just noise, hoping something points in the right direction):

https://github.com/apache/grails-core/issues/15293#issuecomment-3720854215

James Fredley

On 2026/01/01 07:21:38 James Daugherty wrote:
> 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 <mgbiz-yvYIh6MZAuFWk0Htik3J/[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
> >>
> >
>