I agree, but we have a) already invested a large amount of resources to
supply a compiled example for case 1, which in the end led nowhere, and
b) are not at liberty to share our code, so I was trying to point out
the direction any synthethic tests would probably need to aim based on
our experience, should someone who has not yet solved his performance
problems be inclined to create such tests :-)
Cheers,
mg
Am 17.01.2026 um 21:36 schrieb Дилян Палаузов via dev:
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
