You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2020/01/08 09:37:16 UTC
About the performance of indy
Hi all,
The performance of indy has been improved a lot, here is the
report[1]:
Benchmark indy2 VS indy1
indy2 VS cs
CallsiteBench.dispatch_megamorphic 3675% 25.83%
CallsiteBench.dispatch_monomorphic 5.72% 188.62%
CallsiteBench.dispatch_polymorphic 3000% -17.11%
(Note: indy2: the indy with improved performance, indy1: the old indy, cs:
the legacy callsite caching used by default now)
If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for
whether to enable indy by default, it will be another topic...
At last, I want to thank Jochen for reviewing PR1135[2] and thank
Cédric for helping me solve the Gradle dependency usage issue.
Cheers,
Daniel.Sun
[1] https://github.com/apache/groovy/pull/1135#issuecomment-571961230
[2] https://github.com/apache/groovy/pull/1135
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About the performance of indy
Posted by MG <mg...@arscreat.com>.
Don't want to turn this into an endless off topic thread, but:
1. Kotlin is not of the Algol/Pascal/... language tree but a C syntax
language
2. C syntax is the dominant syntax used (C/C++/Java/C#) for a reason
(with Python being the odd man out)
3. The foo : Foo syntax kind of works, as long as there is no
assignment on declaration, because then it becomes foo : Foo =
initialFooVal, which to me is just ugly, since it looks like we are
assigning initialFooVal to type Foo
4. The example was taken from a Kotlin blog, and is the Kotlin syntax
for assignment on declaration when giving an explicit type*
Kind regards,
mg
*As long as you are always using type inference (or in a weakly typed
language such as JavaScript), there is of course no explicit type, and
the syntax becomes clear & concise, the same as in Groovy (def foo =
initialFooVal).
On 09/01/2020 00:46, Angelo Schneider wrote:
> Necause languages like Pascal and Modula II or Ada use:
>
> var_name : TType; // this is a declaration of a variable named
> „var_name“ and of type TType.
>
> However in your example I assume either the var, or the „: Foo“ is
> redundant. Because var is used in Kotline for type interference, if
> I’m not mistaken.
>
> Best Regards
>
> privat: -------------------- www.oomentor.de
> <http://www.oomentor.de> --------------------------
> Angelo Schneider OOAD/UML Angelo.Schneider@oomentor.de
> <ma...@oomentor.de>
> Putlitzstr. 24 Patterns/FrameWorks
> 76137 Karlsruhe C++/JAVA Mob: +49 172 9873893
>
> Am 09.01.2020 um 04:37 schrieb MG <mgbiz@arscreat.com
> <ma...@arscreat.com>>:
>
>> These results look great, Daniel G-)
>>
>> With regards to nomenclature: What is your definition of megamorphic
>> as compared to polymorphic ? The web does not seem to be in complete
>> agreement on these terms - I assume you are referring to the number
>> of call site cache entries needed (monomorphic: 1, polymorphic: > 1,
>> megamorphic: > cache size) ?
>>
>> Cheers,
>> mg
>>
>> PS: Came across some Kotlin code during my web search. Mind still
>> shudders at seeing the syntax
>> var result: Foo= calcFooResult()
>> used in a statically typed language - bloated, hard to read, why are
>> we seemingly assigning a value to a type...
>>
>>
>> On 08/01/2020 17:26, Daniel.Sun wrote:
>>> FYI.
>>> https://github.com/apache/groovy/pull/1135#issuecomment-571961230
>>>
>>>
>>>
>>>
>>>
>>> -----
>>> Apache Groovy committer & PMC member
>>> Blog: http://blog.sunlan.me
>>> Twitter: @daniel_sun
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>
Re: About the performance of indy
Posted by Angelo Schneider <an...@oomentor.de>.
Necause languages like Pascal and Modula II or Ada use:
var_name : TType; // this is a declaration of a variable named „var_name“ and of type TType.
However in your example I assume either the var, or the „: Foo“ is redundant. Because var is used in Kotline for type interference, if I’m not mistaken.
Best Regards
privat: -------------------- www.oomentor.de --------------------------
Angelo Schneider OOAD/UML Angelo.Schneider@oomentor.de
Putlitzstr. 24 Patterns/FrameWorks
76137 Karlsruhe C++/JAVA Mob: +49 172 9873893
Am 09.01.2020 um 04:37 schrieb MG <mg...@arscreat.com>:
> These results look great, Daniel G-)
>
> With regards to nomenclature: What is your definition of megamorphic as compared to polymorphic ? The web does not seem to be in complete agreement on these terms - I assume you are referring to the number of call site cache entries needed (monomorphic: 1, polymorphic: > 1, megamorphic: > cache size) ?
>
> Cheers,
> mg
>
> PS: Came across some Kotlin code during my web search. Mind still shudders at seeing the syntax
> var result: Foo= calcFooResult()
> used in a statically typed language - bloated, hard to read, why are we seemingly assigning a value to a type...
>
>
> On 08/01/2020 17:26, Daniel.Sun wrote:
>> FYI.
>> https://github.com/apache/groovy/pull/1135#issuecomment-571961230
>>
>>
>>
>>
>>
>> -----
>> Apache Groovy committer & PMC member
>> Blog: http://blog.sunlan.me
>> Twitter: @daniel_sun
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
Re: About the performance of indy
Posted by "Daniel.Sun" <su...@apache.org>.
The PR#1135[1] implements the PIC for Groovy indy. As the book
"Efficient Polymorphic Calls" said[2], "If a send is megamorphic(invokes
many different methods), it cannot be handled efficiently by PICs.
Fortunately, such sends are the exception rather than the rule.", so I will
not spend more time to improve the performance for the "exception"...
Cheers,
Daniel.Sun
[1] https://github.com/apache/groovy/pull/1135
[2]
https://books.google.com.ph/books?id=TRTI80RGWjoC&pg=PA20&lpg=PA20&dq=CLR+monomorphic+inline+cache&source=bl&ots=qAoVAiPOvf&sig=ACfU3U2-kxZVXm7lw8ircNKeAxIwmmdcYw&hl=zh-CN&sa=X&ved=2ahUKEwj21d_HlPjmAhUc8XMBHV4KBhYQ6AEwAnoECAoQAQ#v=onepage&q&f=false
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About the performance of indy
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 13.01.20 um 15:49 schrieb Daniel Sun:
> Hi Jochen,
>
> The changed example will run faster than the original one because cache will always be hit for each argument. Actually we can make run even much faster, loop more than 100_000 times, e.g. 1_000_000, because the optimize threshold reaches, the related MH will be linked to the cs.
>
> As you said, we should test it and not just guess ;-)
[...]
>>> def same(String obj) { return obj }
>>> def same(int obj) { return obj }
>>> def same(float obj) { return obj }
>>> for (r in [1, 1.0f, '1.0']) {
>>> for (int i = 0; i < 100_000; i++) {
>>> r.each { same(it) }
>>> }
>>> }
this will first run 100k times with integer as receiver, then 100k times
with float and finally 100k times with String. The old implementation
would here now reset the target 3 times. You implementation will run
into 3 cache misses. The point is, that 100k iterations are supposed to
be enough for the callsite to be optimized, followed by a setTarget in
the old implementation, causing a deopt, and maybe optimization again,
and so on. This has to compare with the cache misses.
if there is really a penalty in the form you expect it, then the my
proposed version can be changed to also use invokeExact and the we could
compare again.
bye Jochen
Re: Re: About the performance of indy
Posted by Daniel Sun <su...@apache.org>.
Hi Jochen,
The changed example will run faster than the original one because cache will always be hit for each argument. Actually we can make run even much faster, loop more than 100_000 times, e.g. 1_000_000, because the optimize threshold reaches, the related MH will be linked to the cs.
As you said, we should test it and not just guess ;-)
BTW, the stack trace is copied from the JIRA issue.
Cheers,
Daniel.Sun
On 2020/01/13 09:17:29 Jochen Theodorou wrote:
>
>
> Am 10.01.20 um 16:14 schrieb Daniel.Sun:
> > Hi Jochen,
> >
> > > If you want to get the maximum performance then I would suggest to
> > work
> > with the guards instead of falling back to a hashed map.
> >
> > Thanks for your suggestions :-)
> >
> > After we constructed the following "tree" MH with guards, we have to set
> > target to link the MH to the related callsite.
> >>
> >> Guard(String)
> >> / \
> >> MH(same(String) Guard(Float)
> >> / \
> >> MH(same(float)) Guard(Integer)
> >> / \
> >> MH(same(int)) Fallback to select
> >
> >
> > But the "setTarget" may cause poor performance because JVM may do some
> > de-opt shown as GROOVY-8298:
>
> nothing goes beyond a test. Really, to be deopt, there has to be an
> optimization first. The tests we did do not reflect this. You have to
> change the examples to something like:
>
> > def same(String obj) { return obj }
> > def same(int obj) { return obj }
> > def same(float obj) { return obj }
> > for (r in [1, 1.0f, '1.0']) {
> > for (int i = 0; i < 100_000; i++) {
> > r.each { same(it) }
> > }
> > }
>
>
> > ```
> > "qtp2078714399-360525": running, holding [771bcf60]
> > at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
> > Method)
> > at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:258)
> > at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154)
> > at
> > org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(Selector.java:909)
> > at
> > org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:969)
> > at
> > org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:228)
> > at
> > java.lang.invoke.LambdaForm$DMH/1665404403.invokeStatic_L3IL5_L(LambdaForm$DMH)
> > at java.lang.invoke.LambdaForm$BMH/1828868503.reinvoke(LambdaForm$BMH)
> > at
> > java.lang.invoke.LambdaForm$reinvoker/1917025677.dontInline(LambdaForm$reinvoker)
> > at java.lang.invoke.LambdaForm$MH/462773420.guard(LambdaForm$MH)
> > at java.lang.invoke.LambdaForm$MH/1947020920.linkToCallSite(LambdaForm$MH)
> > ```
>
> How did you produce that trace?
>
> bye Jochen
>
>
Re: About the performance of indy
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 10.01.20 um 16:14 schrieb Daniel.Sun:
> Hi Jochen,
>
> > If you want to get the maximum performance then I would suggest to
> work
> with the guards instead of falling back to a hashed map.
>
> Thanks for your suggestions :-)
>
> After we constructed the following "tree" MH with guards, we have to set
> target to link the MH to the related callsite.
>>
>> Guard(String)
>> / \
>> MH(same(String) Guard(Float)
>> / \
>> MH(same(float)) Guard(Integer)
>> / \
>> MH(same(int)) Fallback to select
>
>
> But the "setTarget" may cause poor performance because JVM may do some
> de-opt shown as GROOVY-8298:
nothing goes beyond a test. Really, to be deopt, there has to be an
optimization first. The tests we did do not reflect this. You have to
change the examples to something like:
> def same(String obj) { return obj }
> def same(int obj) { return obj }
> def same(float obj) { return obj }
> for (r in [1, 1.0f, '1.0']) {
> for (int i = 0; i < 100_000; i++) {
> r.each { same(it) }
> }
> }
> ```
> "qtp2078714399-360525": running, holding [771bcf60]
> at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
> Method)
> at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:258)
> at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154)
> at
> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(Selector.java:909)
> at
> org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:969)
> at
> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:228)
> at
> java.lang.invoke.LambdaForm$DMH/1665404403.invokeStatic_L3IL5_L(LambdaForm$DMH)
> at java.lang.invoke.LambdaForm$BMH/1828868503.reinvoke(LambdaForm$BMH)
> at
> java.lang.invoke.LambdaForm$reinvoker/1917025677.dontInline(LambdaForm$reinvoker)
> at java.lang.invoke.LambdaForm$MH/462773420.guard(LambdaForm$MH)
> at java.lang.invoke.LambdaForm$MH/1947020920.linkToCallSite(LambdaForm$MH)
> ```
How did you produce that trace?
bye Jochen
Re: About the performance of indy
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Jochen,
> If you want to get the maximum performance then I would suggest to
work
with the guards instead of falling back to a hashed map.
Thanks for your suggestions :-)
After we constructed the following "tree" MH with guards, we have to set
target to link the MH to the related callsite.
>
> Guard(String)
> / \
> MH(same(String) Guard(Float)
> / \
> MH(same(float)) Guard(Integer)
> / \
> MH(same(int)) Fallback to select
But the "setTarget" may cause poor performance because JVM may do some
de-opt shown as GROOVY-8298:
```
"qtp2078714399-360525": running, holding [771bcf60]
at java.lang.invoke.MethodHandleNatives.setCallSiteTargetNormal(Native
Method)
at java.lang.invoke.CallSite.setTargetNormal(CallSite.java:258)
at java.lang.invoke.MutableCallSite.setTarget(MutableCallSite.java:154)
at
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.doCallSiteTargetSet(Selector.java:909)
at
org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setCallSiteTarget(Selector.java:969)
at
org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:228)
at
java.lang.invoke.LambdaForm$DMH/1665404403.invokeStatic_L3IL5_L(LambdaForm$DMH)
at java.lang.invoke.LambdaForm$BMH/1828868503.reinvoke(LambdaForm$BMH)
at
java.lang.invoke.LambdaForm$reinvoker/1917025677.dontInline(LambdaForm$reinvoker)
at java.lang.invoke.LambdaForm$MH/462773420.guard(LambdaForm$MH)
at java.lang.invoke.LambdaForm$MH/1947020920.linkToCallSite(LambdaForm$MH)
```
Cheers,
Daniel.Sun
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About the performance of indy
Posted by Jochen Theodorou <bl...@gmx.org>.
On 09.01.20 19:01, Daniel.Sun wrote:
> Hi Jochen,
>
> I am still thinking about how to improve indy performance further in
> the method overload cases, e.g.
> ```
> def same(String obj) { return obj }
> def same(int obj) { return obj }
> def same(float obj) { return obj }
> for (int i = 0; i < 100000; i++) {
> [1, 1.0f, '1.0'].each { same(it) }
> }
> ```
>
> If we cache both receiver type and argument types, I find the
> performance of this case can be improved a lot, but other cases performance
> is reduced quite a bit too... so I am trying 2 levels cache: the 1st level
> cache is the current cache for receiver type, its size is fixed as 16 by
> default, and I want to add 2nd level cache is for caching argument types,
> its size will be fixed as 16 by default too. The 2 caches are seperated, so
> receiver types kept in 1st level cache will not be cleared, and 2nd level
> cache can provide more hot candidates for better performance.
If you want to get the maximum performance then I would suggest to work
with the guards instead of falling back to a hashed map. The JVM can
quite efficiently check if x is of type X. So for example in the above
case I see something like this (Notes: ASCII art, MH(same(String) means
the method handle to invoke the method same with the parameter type
String, Guard(Integer) a guard checking for the argument type integer,
with positive case on the left and fallback on the right):
>
> Guard(String)
> / \
> MH(same(String) Guard(Float)
> / \
> MH(same(float)) Guard(Integer)
> / \
> MH(same(int)) Fallback to select
Ideally we would also take out the exception unrolling and the switch
point guards in the MH and have them in front of the first argument
chart. Heck in this case even the receiver check could be limited to be
done only once. In the end same(String) calls would perform with about
the same performance and same(int) calls would be slowest, but only by a
minimal margin. A hash based cache is never going to beat two simple
instanceof calls.
bye Jochen
Re: About the performance of indy
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Jochen,
I am still thinking about how to improve indy performance further in
the method overload cases, e.g.
```
def same(String obj) { return obj }
def same(int obj) { return obj }
def same(float obj) { return obj }
for (int i = 0; i < 100000; i++) {
[1, 1.0f, '1.0'].each { same(it) }
}
```
If we cache both receiver type and argument types, I find the
performance of this case can be improved a lot, but other cases performance
is reduced quite a bit too... so I am trying 2 levels cache: the 1st level
cache is the current cache for receiver type, its size is fixed as 16 by
default, and I want to add 2nd level cache is for caching argument types,
its size will be fixed as 16 by default too. The 2 caches are seperated, so
receiver types kept in 1st level cache will not be cleared, and 2nd level
cache can provide more hot candidates for better performance.
Cheers,
Daniel.Sun
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About the performance of indy
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 08.01.20 um 22:37 schrieb MG:
> These results look great, Daniel G-)
>
> With regards to nomenclature: What is your definition of megamorphic as
> compared to polymorphic ? The web does not seem to be in complete
> agreement on these terms - I assume you are referring to the number of
> call site cache entries needed (monomorphic: 1, polymorphic: > 1,
> megamorphic: > cache size) ?
monomorphic: any number of calls of one type only
polymorphic: any number of calls of at max cachesize different types
megamorphic: any number of calls of more than max cachesize different types
In Java a cal of the structure x.foo(bar) is of one type if the type of
x does not change, the type of bar is not relevant beyond the first
selection, since we expect static method selection. If the declaration
type of x is final, then in theory you do not even need to check the
receiver type of x later.
In Groovy we have dynamic method selection, thus we need to check x and
bar all the time, plus code for categories and methods added/replaced
through meta classes. So the number of call types will be much higher in
Groovy, even for Java style code and only in very specific situations
this could be different. Plus some more clutter with when we actually
have the information about the to be selected method.
bye Jochen
Re: About the performance of indy
Posted by MG <mg...@arscreat.com>.
These results look great, Daniel G-)
With regards to nomenclature: What is your definition of megamorphic as
compared to polymorphic ? The web does not seem to be in complete
agreement on these terms - I assume you are referring to the number of
call site cache entries needed (monomorphic: 1, polymorphic: > 1,
megamorphic: > cache size) ?
Cheers,
mg
PS: Came across some Kotlin code during my web search. Mind still
shudders at seeing the syntax
var result: Foo= calcFooResult()
used in a statically typed language - bloated, hard to read, why are we
seemingly assigning a value to a type...
On 08/01/2020 17:26, Daniel.Sun wrote:
> FYI.
> https://github.com/apache/groovy/pull/1135#issuecomment-571961230
>
>
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
RE: About the performance of indy
Posted by "Daniel.Sun" <su...@apache.org>.
FYI.
https://github.com/apache/groovy/pull/1135#issuecomment-571961230
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
RE: About the performance of indy
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
Do "a" and "b" represent time taken, operations completed, some other unit? Are positive values good or bad? You haven't given much to be able to understand and evaluate the benchmark.
-----Original Message-----
From: Daniel.Sun <su...@apache.org>
Sent: Wednesday, January 8, 2020 10:11 AM
To: dev@groovy.incubator.apache.org
Subject: Re: About the performance of indy
Yep, we are comparing the performance of different version of DYNAMIC Groovy.
The percentage formula for "a VS b": (a - b) / b. NOTE: a and b in the formula are scores output by JMH.
Cheers,
Daniel.Sun
-----
Apache Groovy committer & PMC member
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=__vA299pRTL6yfUwM1mf5SGWa5nU8xVnMKB9EN0pcPc&s=CHJ1uNywU9Rv2xReNeP6cF01dUJ0rZc1uZDw6P3GRWA&e=
Twitter: @daniel_sun
--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=__vA299pRTL6yfUwM1mf5SGWa5nU8xVnMKB9EN0pcPc&s=rmiRHf5T7oSTrdz4VPdYyrzzJKL55j3I7zbGh0EvREo&e=
Re: About the performance of indy
Posted by "Daniel.Sun" <su...@apache.org>.
Yep, we are comparing the performance of different version of DYNAMIC Groovy.
The percentage formula for "a VS b": (a - b) / b. NOTE: a and b in the
formula are scores output by JMH.
Cheers,
Daniel.Sun
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About the performance of indy
Posted by Guillaume Laforge <gl...@gmail.com>.
"cs" here stands for "call site", not "compile static".
Guillaume
On Wed, Jan 8, 2020 at 4:36 PM Milles, Eric (TR Tech, Content & Ops) <
eric.milles@thomsonreuters.com> wrote:
> What do the percentages represent in the benchmark results? Is there a
> concern that indy2 vs compile static is negative. A column for indy1 v. cs
> may help understanding.
>
> -----Original Message-----
> From: Daniel.Sun <su...@apache.org>
> Sent: Wednesday, January 8, 2020 3:37 AM
> To: dev@groovy.incubator.apache.org
> Subject: About the performance of indy
>
> Hi all,
>
> The performance of indy has been improved a lot, here is the
> report[1]:
>
> Benchmark indy2 VS indy1 indy2 VS cs
> CallsiteBench.dispatch_megamorphic 3675% 25.83%
> CallsiteBench.dispatch_monomorphic 5.72% 188.62%
> CallsiteBench.dispatch_polymorphic 3000% -17.11%
> (Note: indy2: the indy with improved performance, indy1: the old indy,
> cs: the legacy callsite caching used by default now)
>
> If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for
> whether to enable indy by default, it will be another topic...
>
> At last, I want to thank Jochen for reviewing PR1135[2] and thank
> Cédric for helping me solve the Gradle dependency usage issue.
>
> Cheers,
> Daniel.Sun
> [1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_groovy_pull_1135-23issuecomment-2D571961230&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=jNuuSzXhHSy7pxRPNafKEMTnOkrSyWF1rWM_KD7JXHU&e=
> [2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_groovy_pull_1135&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=ipswUC5w-Uqx1pXYiwtLNOMZH_f0DOnfiv7F5WjFiy0&e=
>
>
>
> -----
> Apache Groovy committer & PMC member
> Blog:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=qg33zvv2H2kOkGfkTMH4uRQNeYFfH363G7XVykVpiAY&e=
>
> Twitter: @daniel_sun
>
> --
> Sent from:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=sHiEpx7s3m9RShQzUhSt2NOphyOFAWarVNI-T9X56jA&e=
>
>
--
Guillaume Laforge
Apache Groovy committer
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
RE: About the performance of indy
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
What do the percentages represent in the benchmark results? Is there a concern that indy2 vs compile static is negative. A column for indy1 v. cs may help understanding.
-----Original Message-----
From: Daniel.Sun <su...@apache.org>
Sent: Wednesday, January 8, 2020 3:37 AM
To: dev@groovy.incubator.apache.org
Subject: About the performance of indy
Hi all,
The performance of indy has been improved a lot, here is the
report[1]:
Benchmark indy2 VS indy1 indy2 VS cs
CallsiteBench.dispatch_megamorphic 3675% 25.83%
CallsiteBench.dispatch_monomorphic 5.72% 188.62%
CallsiteBench.dispatch_polymorphic 3000% -17.11%
(Note: indy2: the indy with improved performance, indy1: the old indy, cs: the legacy callsite caching used by default now)
If nobody rejects the PR1135[2] in 72 hours, I will merge it. As for whether to enable indy by default, it will be another topic...
At last, I want to thank Jochen for reviewing PR1135[2] and thank Cédric for helping me solve the Gradle dependency usage issue.
Cheers,
Daniel.Sun
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_groovy_pull_1135-23issuecomment-2D571961230&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=jNuuSzXhHSy7pxRPNafKEMTnOkrSyWF1rWM_KD7JXHU&e=
[2] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_groovy_pull_1135&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=ipswUC5w-Uqx1pXYiwtLNOMZH_f0DOnfiv7F5WjFiy0&e=
-----
Apache Groovy committer & PMC member
Blog: https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.sunlan.me&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=qg33zvv2H2kOkGfkTMH4uRQNeYFfH363G7XVykVpiAY&e=
Twitter: @daniel_sun
--
Sent from: https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html&d=DwIFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww&m=Sg2Tzt6tcPTC2sqnccD5VwC6u8rajuS4YwnzobPguO0&s=sHiEpx7s3m9RShQzUhSt2NOphyOFAWarVNI-T9X56jA&e=