Re: Groovy > 3 performance

MG <mgbiz-yvYIh6MZAuFWk0Htik3J/[email protected]>
Newsgroups gmane.comp.lang.groovy.devel
Message-ID <[email protected]>
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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.