任何一个系统在被评价的时候,性能总是会被谈论到。
GRAILS作为ROR的GROOVY移植,在性能方面也是会和ROR放在一起来做比较。和ROR一样,GROOVY在开发环境下运行是相当缓慢的。所以GRAILS官方在性能优化的FAQ里面明确提到需要在运行开发环境时通过设置JVM的内存堆的参数(-Xmx512M)来提高性能。
可见,只要提高可用的内存数量,就可以大大提升性能。由于在开发环境中,GRAILS默认使用hsqldb的内存数据库,系统对内存的需求就更为巨大。尤其在表的字段和数量随着应用的复杂程度而不断增加的时候,系统的运行速度会变慢到无可忍受的地步。
所以,从性能的方面而言,如果让系统在开发的时候速度不必让开发人员抓狂的话,从开始就应该放弃使用内存数据库,使用实际的数据库。
及早的使用实际数据库对于GRAILS下系统的开发还有其它的好处。首先,通过对实际数据库的观察,我们可以很清楚的判断程序运行的情况。另外,如果我们是让GRAILS系统在运行的时候创建数据库,我们可以通过数据库的观察确定你使用的domain名称是不是能够正常地驱动数据库的创建。
从语言实现而言,由于GRAILS本身是通过把所有的程序经过编译成java class之后在JVM上运行的,因此,它和实现相同功能的java应用的性能差距不大。唯一的差距在于由于GRAILS本身的框架而增加的一层间接导致的性能上的少许损失。但是,这些损失就和你使用spring框架或者struts框架那样大量使用reflection而导致的性能损失相类似,基本可以忽略。相对于正宗的动态语言Ruby而言,GROOVY的性能显然更令人满意。因为实际上它把动态特性已经在编译的时候一次处理完成了。从C++的观点而言,就是通过一次静态的编译性能损失换取了大量的动态性能。一家之言 :) 。
GRAILS作为ROR的GROOVY移植,在性能方面也是会和ROR放在一起来做比较。和ROR一样,GROOVY在开发环境下运行是相当缓慢的。所以GRAILS官方在性能优化的FAQ里面明确提到需要在运行开发环境时通过设置JVM的内存堆的参数(-Xmx512M)来提高性能。
可见,只要提高可用的内存数量,就可以大大提升性能。由于在开发环境中,GRAILS默认使用hsqldb的内存数据库,系统对内存的需求就更为巨大。尤其在表的字段和数量随着应用的复杂程度而不断增加的时候,系统的运行速度会变慢到无可忍受的地步。
所以,从性能的方面而言,如果让系统在开发的时候速度不必让开发人员抓狂的话,从开始就应该放弃使用内存数据库,使用实际的数据库。
及早的使用实际数据库对于GRAILS下系统的开发还有其它的好处。首先,通过对实际数据库的观察,我们可以很清楚的判断程序运行的情况。另外,如果我们是让GRAILS系统在运行的时候创建数据库,我们可以通过数据库的观察确定你使用的domain名称是不是能够正常地驱动数据库的创建。
从语言实现而言,由于GRAILS本身是通过把所有的程序经过编译成java class之后在JVM上运行的,因此,它和实现相同功能的java应用的性能差距不大。唯一的差距在于由于GRAILS本身的框架而增加的一层间接导致的性能上的少许损失。但是,这些损失就和你使用spring框架或者struts框架那样大量使用reflection而导致的性能损失相类似,基本可以忽略。相对于正宗的动态语言Ruby而言,GROOVY的性能显然更令人满意。因为实际上它把动态特性已经在编译的时候一次处理完成了。从C++的观点而言,就是通过一次静态的编译性能损失换取了大量的动态性能。一家之言 :) 。