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.
1. The rest of the mail assumes that it does, due to:
1. This was the only performance problem we ran into, and ours
is a larg application doing varied stuff written completely
in Groovy.
2. 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)...
1. ...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.
1. Once you have found this, hopefully you will be able to reduce
the number of objects created.,
2. 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
<https://lists.apache.org/thread/8vn8h2w8rpxmyz58bjqtkxmcwv2o6trp>
2.
https://groovy-lang.org/releasenotes/groovy-4.0.html#:~:text=Classic%20bytecode%20generation%20removal
<https://groovy-lang.org/releasenotes/groovy-4.0.html#:~:text=Classic%20bytecode%20generation%20removal>
------------------------------------------------------------------------
*From:* Paul King <pa...@asert.com.au>
*Sent:* Thursday, February 22, 2024 2:15 AM
*To:* dev@groovy.apache.org <dev@groovy.apache.org>
*Cc:* Videla, Gabriel <gvid...@ptc.com>
*Subject:* Re: Performance in Groovy 5
[You don't often get email from pa...@asert.com.au. Learn why this is
important at https://aka.ms/LearnAboutSenderIdentification
<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> 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>
