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%
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
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
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
"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
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
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
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
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
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
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
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,
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
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
14 matches
Mail list logo