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
