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 <[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 <[email protected]> > Reply-To: [email protected] > To: [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 > > > > > > >
