By improvement report do you mean you'd like for me to put in a JIRA for it?
As for performance, I haven't benchmarked it. I'm more wondering for general knowledge as well. We just ported about 600 classes from a proprietary business rule language into static-compiled Groovy, and for that rule execution, CPU performance is a concern (and upcoming dedicated project) as the code runs on a web application refresh to recalculate values. We also use Groovy elsewhere as well in a project that is otherwise written in Java, but since we've moved about a 3rd of the project over to Groovy, a good part of my argument for using Groovy is that we can use Groovy features and DSLs and still keep largely the same performance and compile-time checking as in Java, but use dynamic where it makes sense (for example we use dynamic exclusively in production and consumption of our web service APIs).
From: Jochen Theodorou [mailto:firstname.lastname@example.org]
Sent: Saturday, October 24, 2015 5:07 AM
Subject: Re: Integer primitive division
----------------------------------------------------------------------On 23.10.2015 22:47, Winnebeck, Jason wrote:
> Is there any way to perform primitive integer division in Groovy
> compile static mode? If I do:
> Then it coverts 12 and 2 to Integer objects, calls a method that
> performs BigDecimal division, then calls "as int" (not just intValue)
> on the result, which itself does instanceof checks.
> I tried intdiv, and it is more efficient, but it still converts to and
> from Integer objects so that it can do A.intValue() / B.intValue(),
> and storing that result in an Integer itself.
I think I did do an optimization for this kind of thing for double, but I may not have done that for int... normally if you do something like
int i = 12/2
the compiler should be able to optimize this to a normal int division like in Java for primopts and compilestatic.. checking now I find a
meaning it works for primopts, but not for compilstatic. Probably, because in normal Groovy we do not prevent conversions with loss for numbers, while copilestatic insists of the div resulting in a BigDecimal. And then primopts fail to help compilestatic.
Not sure if I should really qualify that as static compilation bug
As for intDiv... ideally the JVM does optimize the overhead away. But considering optimizations being done here for primopts as well as the invokedynamic version I think some work should be invested here.
An improvement report for this would be a good start
As for "What I'm wondering is if Java is strictly required if performance is a concern with division." Did you check the impact of this?
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.