-
-
Save nobeans/2337510 to your computer and use it in GitHub Desktop.
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!
@nobeans, I tried that out and on my computer:
Linux xxxx 2.6.32-31-generic #61-Ubuntu SMP Fri Apr 8 18:25:51 UTC 2011 x86_64 GNU/Linux
java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
since the variation in that test is on my system about 30%, indy being enable or not makes no difference at all. In fact I would say the average for indy is the same, if not better. But it really depends. two runs of non indy test and you get two quite different averages too.
I would assume that file IO is dominating on my system for this test, thanks to that file#eachLine