I really like Groovy: the syntax is similar to Java and will be standardized. This looks promising and like a good investment into the future so I thought about integrating it into a project I’m working on. But first I wanted to compare code written in Java to the equivalent in Groovy and check the performance.
Some performance tests
Recently I read Code Complete, an excellent book by Steve McConnell, that has got some good ideas about testing performance. According to McConnell’s habit of measuring the code’s performance instead of telling anecdotes I wrote some tests that’ll:
- create an object and call some methods on it
- create a one- and two-dimensional array and fill it with some values
- compare two integers
Have a look at the following chart that shows the results:
There are no bars for some classes because they virtually took no time to execute. On the other hand some tests took too long so I cut them off, i.e.
GroovyArray aren’t displayed in the chart after 105 and 103 test runs respectively.
I ran these tests on a 1,83 GHz Intel Core Duo and used Groovy 1.0 and Java 1.5.0_07 under MacOS X. The tests are everything but accurate and should just give us a rough idea of the performance of Groovy and Java.
What do we learn from these tests?
First off Groovy seems to be slow if you’re making just one test run. The explanation for this are static fields that need to be initialized the first time you instantiate a Groovy class. The
GroovyPersonBean class is a good example of this phenomenon: there’s a peek at the beginning and the next time we get measurable results is at 103 test runs.
If you take a look at the number of test runs, Java seems to be three powers of ten faster than Groovy, e.g. Groovy takes circa 2s at 103 test runs while Java takes 2s at 106 test runs (
GroovyArray). This holds true for almost all test cases.
Improvements in readability? Productivity?
As a side note I thought about the readability of the code. I haven’t used Groovy in a production environment yet, but the things I’ve coded so far just look nice. The learning curve is steep if you’ve got a background in Java and I certainly saved some time writing Groovy code instead of writing the equivalent in Java. I guess that readability, productivity and motivation might go up with Groovy because it’s just fun using it instead of ye good ol’ verbose Java language.
But as I said: since I haven’t tested it in a real project yet, I eventually might have no clue about this.
Although it seems like Groovy is a lot slower compared to Java we have to reconsider the tests I ran. First, there’s the test that creates a bean and calls some setters on it. Even if you create 105 of these groovy beans it’ll just take less than a half of a second. I think that Groovy isn’t losing on this one because who wants to create so many objects in the first place? So I would say that Groovy is well suited as a substitute for regular Java beans; the fact that Groovy generates getters and setters automatically makes it even better.
Second, I created an array and assigned values to it. I haven’t come up with some other tests yet to confirm the assumption that Groovy lacks performance for code that does something. If I have some time to spend I’ll investigate this further. The third pair of tests just compare two integers and because this stands separate from the other tests I don’t go into detail about it.
Coming to a conclusion I would say that you can use Groovy to code beans without imposing a performance penalty. This might not be true for real groovy code, but this has to be investigated further.