lua和groovy都是可以嵌入到java中的脚本语言。lua以高性能著称,与C/C++在游戏开放中有较多使用,groovy是一个基于Java虚拟机(JVM)的敏捷动态语言,在jvm下有着不错的性能。
groovy天生与java有着极高的兼容性,两者间对象无缝存取,支持jsr223。而lua是基于C的,需要调用jni,jni的性能是硬伤。这块网上基本都用luajava,好多年不更新了,不支持jsr223,而且很多方法都没有实现,也不能做到对象无缝存取,比如lua传到java的对象,java用不了。 另一个是luaj,基于java的lua库,快速,稳定,支持jsr223,测试对比用的是这个。 再提一个jnlua,文档里写的很牛逼,支持jsr223,支持双向对象调用,结果根本跑不了,shit。
测试程序都是基于jsr223编写,先经过脚本编译。再运行一遍脚本。 然后统计调用脚本100次消耗的时间,求平均。可以去除编译脚本、初次运行等因素带来的干扰。测试机器为win32机器。
对比结果如下:
LuaLuaj 2.0.2 | Groovy2.0.1 | Jython2.5.3 | Javajdk6 | |
100000次for | 4ms | 2ms | 42ms | 1ms |
100000次整数比较 | 7ms | 9ms | 1ms | |
外部传入大小100000的List<Integer>,迭代相加 | 82ms | 7ms | 3ms | |
创建100000大小的table。并赋值 | 34ms | 38ms | 64ms | |
复杂四则计算100000次 | 480ms | 280ms | 130ms | |
100000记录的group | 578ms | 286ms | 180ms |
可以看出在jvm环境中,groovy的性能基本是lua的2倍,特别是lua调用java传入的对象时,性能更低。 两种脚本语言创建table的性能都比java高。 不要再迷信那些官方的性能测试,不考虑应用的上下文,那些性能测试报告只能做个参考。
附100000次整数比较的测试代码:
import javax.script.Bindings;
import javax.script.Compilable;
import javax.script.CompiledScript;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
public class IntEquals {
public static void main(String[] args) throws ScriptException {
ScriptEngineManager sem = new ScriptEngineManager();
ScriptEngine e = sem.getEngineByExtension(“.lua”);
CompiledScript cs = ((Compilable) e)
.compile(“for i=1,100000 do if i == 100 then end end return 10″);
Bindings luab = e.createBindings();
cs.eval(luab);
long start = System.nanoTime();
for (int i = 0; i < 100; i++) {
cs.eval(luab);
}
System.out.println(“lua script for 100000 time:”
+ (System.nanoTime() – start) / 100000000 + “ms”);
// groovy
e = sem.getEngineByExtension(“groovy”);
cs = ((Compilable) e)
.compile(“for ( i in 1..100000 ) { if(i==100){};}; return 10″);
cs.eval(luab);
start = System.nanoTime();
for (int i = 0; i < 100; i++) {
cs.eval(luab);
}
System.out.println(“groovy script for 100000 time:”
+ (System.nanoTime() – start) / 100000000 + “ms”);
}
}
win下结果 lua:7ms groovy:9ms
mac os下结果 lua:7ms groovy:1ms
http://www.tuicool.com/articles/QbMRFr