Groovy Micro Benchmark Revisited (Groovy is fast…)
Posted by jonchase
Alright, no more Groovy posts for a while after this one. In fact, I hadn’t planned on posting about this again, but I thought it was worth mention.
From the last post, we saw the following results for parsing an XML dataset with about 450 simple elements in it 1,000 times:
- Java: ~9 seconds
- Groovy: ~28 seconds (with new results below…)
I decided to rerun the test for Groovy because of a comment John Wilson left on the first post. He suggested this more concise syntax for the Groovy implementation:
I reran the same benchmark, and I was very, very surprised at the results:
- Java: ~9 seconds
- Groovy:
~28~9 seconds
All I can say is wow. I’m not sure what is happening differently, but I’m happy:)
Any ideas what was taking up so much time in the original Groovy implementation?
Groovy Micro Benchmark
Posted by jonchase
Following on from the previous post (and here’s the last post), here’s a very quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark I did using the code in the last post.
Date set: a String containing roughly 450 XML elements in the form <contact name=”some name” email=”some email” />
Methodology: I wrote driver programs in both Groovy and Java to run the test. Here’s the one from Java (the Groovy one is similar):
As you can see from the code, very quick and dirty. The test iterates 1,000 times and then prints out the time consumed.
I ran the test several times on my laptop (2Ghz, 2GB ram, blah blah blah it doesn’t really matter here) and here are the general results for total execution time for 1,000 iterations:
- Java: ~9 seconds
- Groovy: ~28 seconds
Quite a difference. I suspect part of that has to do with my inefficiency as a Groovy programmer. Certainly though, you can see that there is measurable difference in performance. I wonder what type of XML parser the Groovy implementation uses behind the scenes. The Java implementation uses SAX. If Groovy were using DOM with XmlSlurper, I could see that making a very large difference. Any experts care to chime in?
Now, before you decide to write off Groovy, another metric of interest might be seconds required to develop the code. It was something like this:
- Java: ~ 1,800 seconds - roughly 30 minutes. (First I had to decide what XML library I was going to use - JDOM? Dom4J? Xstream? Then I had to search and search for documentation on JDOM…and of course I had to download JDOM, well, that is, I have to add JDOM as a dependency in my Maven pom.xml (after I looked up the current version of JDOM at the ibiblio repo), and rebuild my Eclipse classpath with the new JAR on it, and then figure out how to use the JDOM API…) I’ve been writing Java for about 6 years, so I consider myself fairly adept.
- Groovy: ~300 seconds - roughly 5 minutes. (I had to find the page on the Groovy wiki that explained how to process XML.) I’ve been writing Groovy for less than 2 weeks.
So there you have it, my quick and dirty, completely unscientific, prone to error, your mileage may vary micro benchmark.
I’m not one to reserve judgment, so here goes:
- First, this is just one example. Comprehensively measuring performance is a complex thing, and this benchmark doesn’t claim to do that. There is no such thing as saying “Groovy is slow”.
- Second, I’d gladly trade the frustration and time requirement of the Java solution for the easier to read and write Groovy solution. Servers are cheap. I’ll almost always choose to pay the price in $$$ (which I can always get more of) rather than time (which I can never have enough of).
Update: here’s the final post in this series.
Groovy is Coming…
Posted by jonchase
I’ve been trying to slowly integrate some Groovy into my normal Java coding. Here’s just one of the reasons why:
Java code:
Groovy code:
Note that this reduction in complexity happens almost everywhere I choose to use Groovy over Java. Of course there are myriad other ways I could have done this in Java (I even tried Xstream but I couldn’t figure part out so I gave up). The point is that the first way I chose to do it in Groovy was natural, expressive, and easy.
Groovy is not going away any time soon. If you’re a Java developer and wish you could move faster, buy the book, read it, and then start integrating Groovy into your daily programming a little at a time. You’ll be happy you did.
And don’t even get me started on Grails…
Update: here are the second and third posts in this series (benchmarks included).
Subscribe to Jon's Blog