Hi Jochen,
1. since, as I said, we could not pinpoint any specific, smaller piece
of code that exhibits the problem, we can alas not supply a test case.
2. But if you guys want to try out this 80% (?) quick fix solution, I
can offer to test it with our framework, as soon as we have
successfully switched to Groovy 5.
Cheers,
mg
Am 14.08.2025 um 09:38 schrieb Jochen Theodorou:
That would be very much appreciated. My problem is a bit the "where to
start while having something real life testable"
and maybe something like
callsite.paths = [SLOW_PATH_0, current logic]
callsite.counter = 0
callsite target = {
if (counter < THRESHOLD) {
increase counter
continue with paths[0]
} else {
continue with paths[1]
}
}
as a first step would already help a bit and would be near the final
solution I drafted in my mail as well
bye Jochen
On 13.08.25 22:11, Milles, Eric (TR Technology) via dev wrote:
I have been following the discussion. Jochen, if you want to work
together on a prototype for this, I can surely help.
------------------------------------------------------------------------
*From:* Jochen Theodorou <blackd...@gmx.org>
*Sent:* Wednesday, August 13, 2025 2:28 PM
*To:* dev@groovy.apache.org <dev@groovy.apache.org>
*Subject:* [EXT] Re: Groovy 5 - Performance / @CompileStatic
External Email: Use caution with links and attachments.
On 10.08.25 22:59, MG wrote:
[...]
3. But, most importantly, as Jochen stated in his last reply:
"Yes, in
the end MethodHandles are faster, but only once optimizations have
run. /And that takes thousands of iterations/. MG for example has
been hit by this."
1. So he thinks he already knows what causes the performance
degradation when using Groovy indy, and already points out
some
way(s) to improve this (independent of the specifics our
project)...
I think it is the cost of initialization. We have to keep that much
lower than we do right now. Sadly you are the only reacting to that mail
so far. I thought I kept it simple enough...
bye Jochen
