Re: Groovy > 3 performance

@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
>
>
>