[
https://issues.apache.org/jira/browse/GROOVY-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18055375#comment-18055375
]
Paul King commented on GROOVY-11842:
------------------------------------
[~blackdrag] What are your thoughts on back-porting this to GROOVY_5_0_X. I am
keen on the slight performance gain for 5 users since it will be our main
supported version for a little while yet. I am not so much interested at this
point in future additional refactorings.
In general, we need to be very careful when back-porting such changes since
IIUC different bytecode is being generated. My understanding is that as an
example, Grails plugins compiled with 5.0.3 (say) would still run fine with a
future 5 version that included this change. Code in such plugins would just
still have the slightly less clean stacktrace. But correct me if I am missing
something.
I was thinking of just not bringing back across the @Deprecated annotations -
not that it would matter much to us but just to not force anyone who might be
using that directly (I know of no-one) to not get extra deprecated warnings
mid-version. I suspect more substantial changes would stay on master. Thoughts?
> Invokedynamic first invocation should not have a line with IndyInterface
> ------------------------------------------------------------------------
>
> Key: GROOVY-11842
> URL: https://issues.apache.org/jira/browse/GROOVY-11842
> Project: Groovy
> Issue Type: Improvement
> Reporter: Jochen Theodorou
> Priority: Major
> Labels: performance
> Attachments: improved_indy.svg, improved_indy_startup.svg,
> screenshot-1.png
>
>
> As can be seen in the IndyInterfaceUsageTest there is a stack trace element
> showing IndyInterface. This is bad for inlining and general performance.
> !improved_indy.svg!
> of course a programm like
> {code:Java}
> int foo(){1}
> int a
> for (int i=0; i<MAX; i++) {
> a = foo()
> }
> {code}
> is not much of a test for anything. It was supposed to show better inlining,
> but unlike Groovy 3 all later Groovy version fail to unroll the loop and
> eliminate the assignment to a for later executions. The graph though shows
> that the branch performance is better than Groov 3 or 4. Not only in the long
> run, but also on start. But be aware the graph above is from the 5th
> iteration of 1k calls to be able to see things more in scale. The first 4
> iterations of 1k calls look like this:
> !improved_indy_startup.svg!
> to actually be able to see differences the iteration size is now 100 calls
> and the y-axis is logarithmic. I want to especially point out how the
> no-primopts variant has similar initial cost as indy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
