Thanks MG and Jochen for your explanations. If we manage to identify the part of our code with the performance issue we'll let you know.
you can switch to Groovy 4 for now, if you tell it to use the old mechanism (I can't remember the setting, it was in one of Paul's replies)... Paul, can you point me to this setting? I did a search but couldn't find it. It would help meanwhile since there are some fixes in Groovy 4 that are not present in Groovy 3. Thanks. ________________________________ From: MG <mg...@arscreat.com> Sent: Saturday, February 24, 2024 2:11 AM To: dev@groovy.apache.org <dev@groovy.apache.org>; Videla, Gabriel <gvid...@ptc.com>; pa...@asert.com.au <pa...@asert.com.au> Subject: Re: Performance in Groovy 5 You don't often get email from mg...@arscreat.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Gabriel, 1. that post about Groovy 3 -> 4 performance degradation was from me. 2. The performance degradation in our case was definitely due the JVM's dynamic call resolution ("indy") being used over Groovy's own implementation. 3. It actually occurs the same in Groovy 3 when switched to using indy (Groovy 3 defaults to the old mechanism, whereas Groovy 4 defaults to using indy). 4. So you can test this by forcing Groovy 3 to use indy, and check if the same performance degradation occurs. * The rest of the mail assumes that it does, due to: * This was the only performance problem we ran into, and ours is a larg application doing varied stuff written completely in Groovy. * No one else having reported any performance issues afaiaao. 5. So you can switch to Groovy 4 for now, if you tell it to use the old mechanism (I can't remember the setting, it was in one of Paul's replies)... * ...but that solution will run out of steam at some point, since the old Groovy callsite resolution mechanism will be blocked by future Java VMs, so at some point in the future Groovy will be "indy" only. 6. In our case, in the end we were able to refactor our code, trading some usability of our in-house framework for creating less short lived temporary objects on the heap, thereby getting back to expected performance, and are now running on the latest Groovy 4. 7. It took quite some time & effort to pinpoint where exactly those "too many objects" where created, since, as it turned out, it where objects representing database Table references for our SQL generator, of which a lot do get created for a short time - just in this one case "a lot" turned out to be orders above other code parts, in a non-obvious way. 8. So if you want to fix this on your side, the advice I can give is to try to isolate a relatively small code segment that can be used as a test case to drill further down & isolate the code part / library that causes the creation of a (very) large number of (temporary) objects. * Once you have found this, hopefully you will be able to reduce the number of objects created., * As I said we did not get lucky & had to accept a workaround, but in theory you might find that creatings so many objects is actually a bug ;-) 9. On the Groovy side of things there was some activity on this a short while ago, and I am also waiting on some update, to see if we will be able to go back to our older, more convenient implementation... :-) Cheers, mg On 23/02/2024 23:30, Videla, Gabriel wrote: We are working on several aspects which will improve performance. We'll be sure to add further details in the release notes if everything goes to plan. Good to know, thanks. Is there a particular aspect of performance that is of particular importance to you? Our application was upgraded to Groovy 4 but after a performance test showed it was slower we had to go back to Groovy 3. I did a search and found a discussion[1] of someone who also noticed degradation when trying to use Groovy 4. Indy code was suggested as a possible cause but no conclusion was reached. I also noticed that the Groovy 4 release notes[2] mentions that there were numerous speed improvements because previously "indy" code was noticeably slower than "classic" bytecode. 1. https://lists.apache.org/thread/8vn8h2w8rpxmyz58bjqtkxmcwv2o6trp 2. https://groovy-lang.org/releasenotes/groovy-4.0.html#:~:text=Classic%20bytecode%20generation%20removal ________________________________ From: Paul King <pa...@asert.com.au><mailto:pa...@asert.com.au> Sent: Thursday, February 22, 2024 2:15 AM To: dev@groovy.apache.org<mailto:dev@groovy.apache.org> <dev@groovy.apache.org><mailto:dev@groovy.apache.org> Cc: Videla, Gabriel <gvid...@ptc.com><mailto:gvid...@ptc.com> Subject: Re: Performance in Groovy 5 [You don't often get email from pa...@asert.com.au<mailto:pa...@asert.com.au>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Gabriel, We are working on several aspects which will improve performance. We'll be sure to add further details in the release notes if everything goes to plan. Is there a particular aspect of performance that is of particular importance to you? Cheers, Paul. On Thu, Feb 22, 2024 at 8:01 AM Videla, Gabriel <gvid...@ptc.com><mailto:gvid...@ptc.com> wrote: > > Hi Groovy devs > > I was wondering if we should expect some performance improvements in Groovy 5 > compared to Groovy 4. I checked the release notes[1] and changelogs[2] for > Groovy 5 and I didn't see any clear reference to performance improvements so > I thought of asking here. > > Thanks > Gabriel > > 1. > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroovy-lang.org%2Freleasenotes%2Fgroovy-5.0.html&data=05%7C02%7Cgvidela%40ptc.com%7C6388346a435f44bd5bda08dc3343bf23%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C638441613280211984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ijZyZ561gzqKcrGIOHXM9rbp0x0YZ6GLib8ITwtvTnU%3D&reserved=0<https://groovy-lang.org/releasenotes/groovy-5.0.html> > 2. > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroovy-lang.org%2Fchangelogs%2Fchangelog-5.0.0-unreleased.html&data=05%7C02%7Cgvidela%40ptc.com%7C6388346a435f44bd5bda08dc3343bf23%7Cb9921086ff774d0d828acb3381f678e2%7C0%7C0%7C638441613280222351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=703JVhRhXeyHaQKfhtL7Md5B6JnUJWKk6FSpvm317nU%3D&reserved=0<https://groovy-lang.org/changelogs/changelog-5.0.0-unreleased.html>
