Re: Groovy 5 - Performance / @CompileStatic

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 <[email protected]>
>> *Sent:* Wednesday, August 13, 2025 2:28 PM
>> *To:* dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected] <dev-GSC0n/0aZo1d/SJB6HiN2Ni2O/[email protected]>
>> *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
>>
>