Summarized and translated my tweets about groovy at 2012-04-07

gistfile1.txt

When I decompiled a compiled code with @CompileStatic, I found something there:
- @TypeChecked annotations there. (it's good)
- compareTo was compiled as primitive code instead of a call of ScriptBytecodeAdapter.
- There are unnecessary null in places.
- The decompiled result seems curious. It's a little inefficient.
    - By Groovy++: (right.getColor()==BLACK)
    - By Groovy2.0b @CompileStatic: ((right.color==BLACK ? 1 : 0) !=0)

--------------
Groovy source:
--------------
import groovy.transform.CompileStatic

@CompileStatic
class Simple {

    def method(int a, int b, int c) {
        if (a == 1 || b == 1 || c == 1) {
            return true
        }
        return false
    }
}
--------------
Decompiled of the class copmiled with CompileStatic:
--------------
import groovy.lang.GroovyObject;
import groovy.lang.MetaClass;
import groovy.transform.TypeChecked.TypeCheckingInfo;

public class Simple
  implements GroovyObject
{
  public Simple()
  {
    Simple this;
    MetaClass localMetaClass = $getStaticMetaClass();
    this.metaClass = localMetaClass;
  }

  @TypeChecked.TypeCheckingInfo(inferredType="AAlDbGFzc05vZGUAAAFaAP////8=", version=1)
  public Object method(int a, int b, int c)
  {
    if (((a == 1) ? 1 : 0) == 0);
    if (((((b == 1) ? 1 : 0) != 0) ? 1 : 0) == 0);
    if (((((c == 1) ? 1 : 0) != 0) ? 1 : 0) != 0) { //------[1]
      return Boolean.valueOf(true);
    }
    return Boolean.valueOf(false); return null; // ----[2]
  }

  static
  {
    __$swapInit();
    long l1 = 0L;
    __timeStamp__239_neverHappen1333898122602 = l1;
    long l2 = 1333898122602L;
    __timeStamp = l2;
  }
}
--------------
Tests
--------------
import spock.lang.*

class SimpleSpec extends Specification {

    def simple

    def setup() {
        simple = new Simple()
    }

    def ""() {
        expect:
        simple.method(a, b, c) == result

        where:
        a | b | c | result
        0 | 0 | 0 | false
        0 | 0 | 1 | true
        0 | 1 | 1 | true
        1 | 1 | 1 | true
        1 | 0 | 0 | true
        0 | 1 | 0 | true
        0 | 0 | 1 | true
    }
}
--------------
[1] is the very curious, but tests are all green...
2nd return of [2] is unnecessary.

***

A performance of latest HEAD of master (0c2b64) without indy option is almost as same as released 1.8.6.
@StaticCompile's performance is ten times faster than them, and almost as same as Groovy++'s one. It's great work!

And now, I don't know the usage of indy option...

ok, I take that with the IO back. I tried it with a different version and that one was even slower.

running with jdk7u3 (build 1.7.0_03-b04) the results look similar. For non indy I get values from 213-299 ms and for indy I get values from 153-196 ms, and the averages (10 tries) are at 245 (-32/+54) for normal Groovy and 180ms (-37/+16) for indy. And judging from the variation normal Groovy has a tendency to 213, while indy has a tendency to 196. That would make indy still 10% faster than normal Groovy of course.. All in all the values are on average better for indy now actually. Before the values did overlap more.

Anyway... indy being 9 times slower is something I cannot reproduce

One more interesting part... my fastest results are still only half the speed of yours, while my indy results are around 4.5 times faster.

I've caught the flu since Friday...

No worries, take care!