Tuesday, February 19, 2008

Groovy Performance Woes?

[Copied from JRoller blog]

These days, everyone's got something to say about Groovy. Whether it's "the good, the bad or the ugly," Groovy is making great leaps with all its deserved, or undeserved, publicity. With every tool available to the software developer, there are pros and cons; scenarios in which the tool works miracles or reaps havoc. The main determining factor of success or failure is attitude.

Attitude! "An organismic state of readiness to respond in a characteristic way to a stimulus." (Dictionary.com) It is that which makes or breaks the constructs of our lives. "Everything can be taken from a man but ... the last of the human freedoms - to choose one's attitude in any given set of circumstances, to choose one's own way." (Viktor Emil Frankl) "Happiness is an attitude. We either make ourselves miserable, or happy and strong. The amount of work is the same." (Francesca Reigler) My beautiful wife brought to my attention a website which reminds me time and again just how important attitude is in our everyday life. Attitude is the difference between happiness and misery.

This mindset applies just as whole-heartedly to software development. We can make the best of and improve on the tools we have, or dwell on their problems; "the amount of work is the same." Groovy, as with all tools, has its pros and cons. But I won't go into its cons; there's enough of that out there. I'm here to tell you how Groovy has proven to be a tool capable of great strides. Groovy has provided me with the ability to create a wonderful database migration tool. It has endowed me with a level of flexibility capable of migrating data from legacy mainframe and Windows sources containing some more than 100 million records to a newly created database. Migrating one set of records includes some 100+ SQL statements to read, insert and update records (and that's with query resultset caching enabled for static data). Granted, Groovy isn't doing all of the legwork (Spring Framework, Hibernate and Drools play a big role as well), but it is the glue which ties everything together.

This all happens in a matter of seconds. In three seconds, some 200+ Groovy scripts are executed as data transformation tasks. The first time scripts are encountered, they are dynamically compiled to class files using Groovy's ClassLoader and CompilationUnit. Subsequent script executions do not require compilation, even across JVM instantiations. Roughly 5% of the application time is spent in Java and Groovy code. Most of the rest of the time is spent waiting on I/O requests. That works out to about 150 milliseconds in Java and Groovy code, per set of records being migrated, to massage the data. Considering the volume of data and number of business rules being applied, this is quite an achievement.

I hope to have some time in the near future to put together a small test application demonstrating the use of GroovyClassLoader and CompilationUnit to compare a Groovy application's performance with and without the compilation step. Depending on your requirements, using Groovy as glue code could be just as performant as using Java. Groovy can help reduce a project's total man-hours, decrease other resource consumption, increase productivity and provide flexibility to change in key areas. That is, if you have the right attitude.