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
