Re: Groovy > 3 performance

Hi Дилян,

I can provide a couple of real applications with measurements on specific
code to demonstrate the issue.

As with MG the impact is on a specific area (in our case GSP generation)
from Gails 6/Groovy 3 to Grails 7/Groovy 4.

We do server side rendering and the performance issue, even if still
acceptable in our use cases, is noticeable to a trained eye.

Cheers,

Gianluca Sartori
--
https://dueuno.com


On Sat, 17 Jan 2026 at 21:37, Дилян Палаузов via dev <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]>
wrote:

> Hello,
>
> I do not think that this is going to make progress, until somebody shares
> a minimal example, which has performance differences between INDY and
> classic bytecode generation. That is: .groovy files, build environment and
> instructions how to run the files to notice significant performance
> difference.
>
> Greetings
> Дилян
>
>
>
>
>
>
> -----Original Message-----
> From: MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]>
> Reply-To: dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]
> To: dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected], Jochen Theodorou <[email protected]>
> Subject: Re: Groovy > 3 performance
> Date: 17/01/26 22:27:59
>
>
> Hi .+,
>    1. It imho bears repeating, that we faced 2 sperate performance
> problems in our Groovy framework/applications when enabling the INDY call
> site mechanism:
>          1. The performance of creating a large number of short lived,
> small objects, which happened in a very obfuscated way in a very specific
> part of our code, was about 4x slower.
>                1. After finally pinpointing the culprit, we worked around
> that by refactoring our code - trading losing some framework-user
> convenience for needing to create way less (helper) objects.
>          2. Executed code seemed to "leak performance everywhere" when
> methods were called.
>                1. As stated before, switching our two most low level
> framework modules to @CompileStatic worked around this problem.
>    2. The first problem should be reproducable by creating a large enough
> variety of small objects, comparing INDY with non-INDY performance.
>    3. Since it seems the second problem does not occur in smaller projects
> or simple synthetic test code, I assume they also need a "large enough"
> variety of call sites, which could point to how a more complex synthetic
> case would need to be constructed.
>    4. It might also be interesting to know if the Grails performance
> problems are related to problem area 1, 2, or both...
> Cheers,
> mg
>
>
>
> Am 17.01.2026 um 17:50 schrieb Jochen Theodorou:
>
> > On 16.01.26 10:22, Gianluca Sartori wrote:
> >
> > > Hi Jonny,
> > >
> > >  I've used chatGPT just to raise questions more than give a solution.
> I am unfortunately not in the position to work on it, I don't have
> experience on language development (I am sure the Assembly compiler I
> developed when I was in High School does not qualify).
> > >
> >
> >  I would say it is a start. This is not that different from implementing
> an advanced feature in an application.
> >
> >
> > > At the moment the role I can play is to make sure we don't
> forget about performance, because what's happening is that we are degrading
> instead of improving.
> > >
> > >  I am aware that this is not an easy task and I don't want to sound
> rude It's just that I'm writing a bit in a hurry.
> > >
> >
> >  I appreciate your efforts. What would be really nice would be to
> concentrate on a single small problem and have that as a small program
> without Grails. Then I can analyze the heck out of it to maybe find a
> solution for that specific problem
> >
> >  bye Jochen
> >
> >
>
>
>