Hi Gabriel,
1. I checked our configuration, and we used the following line in our
Groovy configuration file:
1. configuration.optimizationOptions.indy = false // Disable
invoke-dynamic (indy) usage
2. If you don't have a Groovy config file in your project yet:
1. For our IntelliJ build it suffices to put a file named e.g.
groovycConfig.groovy in our project (which in your case only
needs to contain the line abve (no imports)).
2. Then tell IntelliJ under Settings\Groovy Compiler\Path to
configscript where the file is located.
3. If you use Gradle, Maven, etc you will have to check where the
file needs to go.
Cheers,
mg
On 01/03/2024 23:30, Videla, Gabriel wrote:
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.
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> <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
<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>
