今天做了个小实验，关于Groovy性能

//使用groovy的语法去编写
long time = System.currentTimeMillis()
10000.times {
int i = 0;
1000.times{ val->
i += val
}
}
println "${System.currentTimeMillis() - time} ms"

//使用Java的语法去编写
time = System.currentTimeMillis();
int i = 0;
for(int x= 1;x<10000;x++) {
for(int y=1;y<1000;y++)  {
i=i+y;
}
}
System.out.println(i + " " + (System.currentTimeMillis() - time) +" ms");

执行结果分别是：
700032704 14531 ms
700032704 15875 ms

而第二部分代码写在Java类中的执行结果是：
700032704 16 ms


能基本说明两个问题，一，在Groovy中使用Java的语法，不会带来性能上的提升；二，Groovy在运行性能上和Java还是有较大差距的。

同样的逻辑，使用Ruby1.9，执行时间为3578.0 ms。

这样的结果我不甘心，于是，我在Groovy中调用了Java的代码：
time = System.currentTimeMillis()
JavaTest.main(null);
println "${System.currentTimeMillis() - time} ms"

执行结果还是700032704 16 ms。呵呵，看来如果需要进行大数据量的运算，还是先写到Java中吧，好在Groovy可以直接调用Java的代码。

"进行大数据量的运算"当然是用JAVA或者C来写咯...
GROOVY要充分利用它DYNAMIC LANGUAGE的特性...发扬长处...

http://www.jroller.com/rants/entry/why_is_groovy_so_slow
其实关键要清楚自己的性能是在那里，Groovy并不是万能的灵丹妙药，关于why groovy is slow，在groovy的maillist也有讨论。

可以肯定的是，Groovy绝对比Java要慢，而且要慢很多。不过有没有这里的差距，实在不好说。说实在的，这里没有写清楚Groovy的版本、Java的版本以及测试的环境。而且用System.currentTimeMillis()来取时间不可取。我曾经用这种方法实验过，无法实际反映花费的时间。

下面是国外的测试，比你的测试要好不少。你参考参考。
http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark

接受不了意见发什么帖子，这里不是一言堂

好。你说我不能动摇你的实验。那我就动摇一下。还就用你的代码。不过你这种计时方式确实不科学。误差太大，无法准确记录程序实际消耗的时间。

首先，我说明一下我的环境，省得说我欺负你。
老IBM T40笔记本一台。PM1.5G，512M内存，30G4500转硬盘，独立显卡。装XPSP2系统。groovy是1.5.1，Java是6.0 update3。Java的环境是Eclipse3.3。机器因为装了太多IBM附带工具和金山2008杀毒软件，启动后内存占用约350M，Eclipse启动后，占用约500M。
首先是你在groovy中的程序。
//使用groovy的语法去编写
long time = System.currentTimeMillis()
10000.times {
int i = 0;
1000.times{ val->
i += val
}
}
println "${System.currentTimeMillis() - time} ms"

//使用Java的语法去编写
time = System.currentTimeMillis();
int i = 0;
for(int x= 1;x<10000;x++) {
for(int y=1;y<1000;y++) {
i=i+y;
}
}
System.out.println(i + " " + (System.currentTimeMillis() - time) +" ms");
发现你java部分贴错了，是x<=10000和y<=1000。
这两个我的机器里执行，消耗在21000到23000ms之间。比你的慢，估计是机器的缘故。
但是，我发现你写得groovy循环不对，我没有在我找到的资料中发现你这种循环方法，所以我使用了标准的for循环。
long time = System.currentTimeMillis()
int i = 0;
for (int x in 1..10000 ) {
    for (int y in 1..1000) {
        i+=y;
    }
}
println "${i},${System.currentTimeMillis() - time} ms";
不知道你哪里找的循环方法，我这是groovy标准的for循环。
编译后执行，710032704,11577 ms，没什么浮动
控制台执行，710032704,12177 ms,1000ms左右浮动
所以说，你的循环代码有问题，我按标准的写法，速度快了一倍。

然后说Java的执行
Eclipse环境下，纯Java代码消耗20到30ms。把int和long换成Integer和Long，约610 ms。

看看你原来的代码，在我的环境下，21000/30 = 700倍速度。
我修改的代码，11577/30 = 385倍速度。
我觉得用基本类型和对象去拼比较无赖，所以测了一个对象的，用Integer和Long代替了int和long，11577/610=18.97倍。以动态语言对静态语言，差10倍20倍的速度，不能算慢吧？
也就是说，跑这个代码，groovy最少可以做到java20分之一的速度。当然，因为采用了你这种不科学的计算，我的误差很大。
你也可以看到，控制台执行的时候，最低21000多，最高到过23000。误差约2秒。这种测试都能有这么大误差。可见计时的不精确。
你这个测试是“以groovy之短攻java之所长”。动态语言对于这种计算是最慢的。因为要每计算一次都要判断类型等工作。所以花费时间很长。但是即使如此，我也可以做到最低20倍速度差。总比你14000多对16，差约875倍小。

你是想用对象类型去搞数值计算？行为艺术吗？
我的结论是，在进行复杂数值计算是用Java去写。20倍的差距还小啊？算推翻我结论啦？

我的结论是复杂数值计算用汇编。：D

用对象计算是行为艺术？那BigDecimal呢？精确浮点运算你不用这个，保证误差哭死你。
动态语言比静态语言在速度上有数量级的差距是肯定的，没有人能说不对。我从来也没打算要证明groovy比java快（这是不可能的）。
我主要说的是你测试的结果不正确。性能测试不是这么来做的。我用重复你测试的办法，主要是要说明你测试的方法不正确。
首先，这种测试没有意义，用groovy最差的地方去和java最快的地方做对比，有意义吗？熟悉动态语言和静态语言的人都知道，两者的差距至少要有1个以上的数量级（20倍算少的）。其次，你的时间取值方法的误差太大，我用你的取值方式，误差达到秒级；再次，因为你测试用例有问题，两者的差距远没有你测试的那么大，我的groovy按照标准写法，性能立刻提高一倍。
你这种测试除了吓跑没接触过groovy的新手，严重误导大家对groovy的看法外，没有任何作用。因为你测出来的速度差距实在是超级大。
初学者是很难分析这些性能测试到底有什么意义的，他们只知道groovy比java慢800多倍。
结果在适合使用groovy等动态语言的地方，有了这种先入为主意识的人也会拒绝动态语言，他们的理由就是，groovy比java慢800多倍。

更新了一下代码：
time = System.currentTimeMillis();
i = 0;
for(int x in  0..9999) {
for(int y in 0..999)  {
i+=y;
}
}
System.out.println(i + " " + (System.currentTimeMillis() - time) +" ms");
确实比原来要快一倍，但不管怎么说，在Groovy中使用Java进行运算，是绝对正确的！
你在说我不对的时候，也有不少错误。是x<=10000和y<=1000，算出来的结果不正确的，逻辑都搞不正确还谈什么测试性能。
Groovy存在的价值更多的体现在它与Java的亲密关系上。不管什么高手老鸟，都不会介意在Groovy中用Java吧？
我的测试本身也不是用于比较Groovy和Java，我想比的是Ruby。我想说既然直接比比不过，就请Java出面好了。这是被你一步一步引入误区的！