About the performance of indy

2020-01-08 Thread Daniel.Sun
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%

+= and -= no longer rejected in assertion statement in Groovy 3

2020-01-08 Thread Marcin Zajączkowski
Hi, Playing with the failures which Groovy 3 brought to Spock tests itself, I noticed that Groovy 3 no longer rejects += and -= if used in an assertion statement: > def a = 1 > assert a += 1 //passes > assert a == 2 //passes While it behaves consistently, I wonder if that change it was purposely

Re: += and -= no longer rejected in assertion statement in Groovy 3

2020-01-08 Thread Daniel.Sun
Hi Marcin, Thanks for your reporting the issue. Would you mind to submit a JIRA ticket to track it? 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

2020-01-08 Thread Milles, Eric (TR Tech, Content & Ops)
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 Sent: Wednesday, January 8, 2020 3:37 AM To: d...@groovy.incubator.apache.org S

Re: About the performance of indy

2020-01-08 Thread Guillaume Laforge
"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.mil...@thomsonreuters.com> wrote: > What do the percentages represent in the benchmark results? Is there a > concern that indy2 vs compile static is neg

Re: About the performance of indy

2020-01-08 Thread Daniel.Sun
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_s

RE: About the performance of indy

2020-01-08 Thread Milles, Eric (TR Tech, Content & Ops)
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 Sent: Wednesday, January 8, 2020 10:11 AM To: d...@groovy.incub

RE: About the performance of indy

2020-01-08 Thread Daniel.Sun
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: += and -= no longer rejected in assertion statement in Groovy 3

2020-01-08 Thread Marcin Zajączkowski
On 2020-01-08 14:41, Daniel.Sun wrote: > Hi Marcin, > > Thanks for your reporting the issue. Would you mind to submit a JIRA > ticket to track it? Done: https://issues.apache.org/jira/browse/GROOVY-9360 Marcin -- https://blog.solidsoft.info/ - Working code is not enough

Re: += and -= no longer rejected in assertion statement in Groovy 3

2020-01-08 Thread Søren Berg Glasius
Hi Marcin, I think it makes sense, that it does not fail, as a +=1 returns 2 which by Groovys asBoolean is true. I am more inclined to say that Groovy 2.x had a bug, that was accepted as a compile error. Just my two cents worth. Best regards / Med venlig hilsen, Søren Berg Glasius Hedevej 1, Gl

Re: += and -= no longer rejected in assertion statement in Groovy 3

2020-01-08 Thread MG
Hmmm - to me an assertion should not have a side effect, so Groovy 2.x rejecting code like that, where the side effect is easily detected, seems proper to me... (The fact that Groovy has a way of interpreting the non-Boolean result as Boolean through the Groovy-truth rules you mention is of cour

Re: About the performance of indy

2020-01-08 Thread 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,

Re: About the performance of indy

2020-01-08 Thread Angelo Schneider
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 mi

Re: About the performance of indy

2020-01-08 Thread MG
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 lo