Re: Groovy > 3 performance

 1. Evidently if we had a compact source sample, progressing towards
    fixing this would most likely be easy, but in the absence of that I
    was just trying to give the feedback I can.
 2. I might misinterpret what you are trying to say, but primitive
    optimizations playing a role would suprise me, since what we do a
    lot in our code is (deeply) nested GStrings with a lot of embedded
    objects representing database table and column references, created
    using reflection, many of them short lived.
 3. The code that does these operations is in the 2 low level modules
    that fixed the performance problems when we switched them to 
    @CompileStatic.

Am 19.01.2026 um 07:22 schrieb Jochen Theodorou:
> I was talking about a specific case and without primitive optimizations.
>
> On 1/18/26 22:54, MG wrote:
>> @And for the long run the performance is actually comparable:
>>
>>  1. I want to reiterate that this is /not /what we observered in any of
>>     the real world cases we used as benchmarks.
>>  2. While performance typically improved slightly with more iterations,
>>     this never led to a convergence towards the same runtime behavior.
>>  3. In addition for many real life use cases it would not matter/help
>>     even if performance became identical between INDY & non-INDY after,
>>     say 1000 or 10000 calls, because this is not a threshold ever
>>     reached in practice, since we e.g. auto restart our application each
>>     night.
>>  4. Imho therefore performance would need to be fixed in a way that
>>     works from the first call, not only at any point in the future...
>>
>> Cheers,
>> mg
>>
>> Am 18.01.2026 um 06:23 schrieb Jochen Theodorou:
>>>
>>>
>>> On 1/17/26 21:36, Дилян Палаузов 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.
>>>
>>>
>>> That in itself is actually not so difficult. See GROOVY-11842 for 
>>> example. While the issue itself is about something being in the 
>>> callstack, that should not be there, I there also talk about how 
>>> Groovy 3 with and without primitive optimizations performs here in 
>>> the first few iterations. And for the long run the performance is 
>>> actually comparable.
>>>
>>> File:
>>>
>>> int foo(){1}
>>>
>>> int a
>>> long t1,t2
>>> O_MAX = 1000
>>> long[] ts = new long[O_MAX]
>>> for (int o=0; o<O_MAX; o++) {
>>>   t1 = System.nanoTime()
>>>   for (int i=0; i<10_000; i++) {
>>>     a=foo()
>>>   }
>>>   t2 = System.nanoTime()
>>>   ts[o] = t2-t1
>>> }
>>>
>>> def f = new File("out.txt")
>>> for (int i =0; i<O_MAX; i++) {
>>>  f << i +": " + ts[i] + "\n"
>>> }
>>> println "done"
>>>
>>>
>>> Environment: just java command line with GroovyMain or groovy command.
>>>
>>> But what does it actually say? And is this really relevant in a big 
>>> application? Those are difficult to answer.
>>>
>>> And that is your whole point I assume. it needs simple enough to 
>>> actually get what you test, but complex enough to be relevant for 
>>> the application. This one here surely is not
>>>
>>> bye Jochen
>>>
>>>
>>>
>>
>