Groovy 学习笔记3 运行效率
第一篇笔记里面，我说groovy运行的居然还满快的，其实是个误会了。我上次做八皇后还是在8080上面用basic做的，和现在奔四上面的groovy相比是没有意义的。特地又做了个对比试验：
queens.groovy
int q=9
int[] i=new int[q]
int count=0
long t = System.currentTimeMillis();
scan(0)
println("totle results:"+count)
println("totle time:"+(System.currentTimeMillis()-t));
def scan(n){
if (n==q){
println(i.toList())
count++
return
}
i[n]=0
while(i[n]<q){
i[n] = i[n]+1
if (check(n))
scan(n+1)
}
}
def check(n){
if (n>0)
for (j in 0..n-1)
if (i[j]==i[n] || i[j]-i[n]==j-n || i[j]-i[n]==n-j )
return false
return true
}
运行结果是：totle time:7271 （为了用groovy控制台运行的，直接用groovy命令运行还要慢一点）
java呢？
queens.java:
public class queens
{
static int q=9;
static int[] i=new int[q];
static int count=0;
public static void main(String[] args){
long t = System.currentTimeMillis();
scan(0);
System.out.println("totle results:"+count);
System.out.println("totle time:"+(System.currentTimeMillis()-t));
}
private static void scan(int n){
if (n==q){
for (int k=0;k<q;k++) System.out.print(i[k]+(k==q-1?"\n":","));
count++;
return;
}
i[n]=0;
while(i[n]<q){
i[n] = i[n]+1;
if (check(n)){
scan(n+1);
}
}
}
private static boolean check(int n){
int j=0;
while(j<n){
if (i[j]==i[n] || i[j]-i[n]==j-n || i[j]-i[n]==n-j ){
return false;
}
j++;
}
return true;
}
}
运行结果是：totle time:791
每次运行花费的时间略有不同，大致相差10倍左右。
能说这是脚本语言天生的缺陷吗？我们来看看同样是类似java语法的脚本语言javascript在IE里面的速度：
<SCRIPT LANGUAGE="JavaScript">
<!--
var q=9
var i=[]
var count=0
var d = new Date();
scan(0)
document.write("totle results:"+count+"<br>")
document.write("time used:"+(new Date()-d)+"<br>")
function scan(n){
if (n==q){
document.write(i+"<br>")
count++
return
}
i[n]=0
while(i[n]<q){
i[n] = i[n]+1
if (check(n)){
scan(n+1)
}
}
}
function check(n){
var j=0;
while(j<n){
if (i[j]==i[n] || i[j]-i[n]==j-n || i[j]-i[n]==n-j ){
return false
}
j++
}
return true
}
//-->
</SCRIPT>
运行结果是： time used:1241
只比java慢了不到一倍，看来groovy还差的太远了。
把groovy编译的class文件反编译了一下，看到groovy生成的代码效率确实是太低了，我们就看循环最内层的check函数把：
def check(n){
if (n>0)
for (j in 0..n-1)
if (i[j]==i[n] || i[j]-i[n]==j-n || i[j]-i[n]==n-j )
return false
return true
}
编译后变成
public Object check(Object obj)
{
if(ScriptBytecodeAdapter.compareGreaterThan(obj, new Integer(0)))
{
Object obj1 = null;
for(Iterator iterator = ScriptBytecodeAdapter.asIterator(ScriptBytecodeAdapter.createRange(new Integer(0), ScriptBytecodeAdapter.invokeMethod(obj, "minus", ((Object) (new Object[] {
new Integer(1)
}))), true)); iterator.hasNext();)
{
Object obj2 = iterator.next();
Object obj3 = null;
if(ScriptBytecodeAdapter.asBool(ScriptBytecodeAdapter.asBool(ScriptBytecodeAdapter.compareEqual(ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.getGroovyObjectProperty(this, "i"), "getAt", ((Object) (new Object[] {
obj2
}))), ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.getGroovyObjectProperty(this, "i"), "getAt", ((Object) (new Object[] {
obj
})))) || ScriptBytecodeAdapter.compareEqual(ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.getGroovyObjectProperty(this, "i"), "getAt", ((Object) (new Object[] {
obj2
}))), "minus", ((Object) (new Object[] {
ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.getGroovyObjectProperty(this, "i"), "getAt", ((Object) (new Object[] {
obj
})))
}))), ScriptBytecodeAdapter.invokeMethod(obj2, "minus", ((Object) (new Object[] {
obj
})))) ? ((Object) (Boolean.TRUE)) : ((Object) (Boolean.FALSE))) || ScriptBytecodeAdapter.compareEqual(ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.getGroovyObjectProperty(this, "i"), "getAt", ((Object) (new Object[] {
obj2
}))), "minus", ((Object) (new Object[] {
ScriptBytecodeAdapter.invokeMethod(ScriptBytecodeAdapter.getGroovyObjectProperty(this, "i"), "getAt", ((Object) (new Object[] {
obj
})))
}))), ScriptBytecodeAdapter.invokeMethod(obj, "minus", ((Object) (new Object[] {
obj2
})))) ? ((Object) (Boolean.TRUE)) : ((Object) (Boolean.FALSE))))
return Boolean.FALSE;
}
}
return Boolean.TRUE;
}
一切都是object，做任何事情都是invokeMethod，两个整数的比较居然要写将近400个字符的代码，光看代码量都可以吓倒我了。这是我们期待的脚本语言吗？
为了减少编码量要花费10倍的运行效率做代价，我认为这个代价太高了。还是等待groovy的继续改进吧。