« April 2008 | Main | June 2008 »

May 2008 Archives

May 4, 2008

Groovy Faster than Ruby? Apparently.

I kind of brushed over Alex's speed improvements in the recent Groovy 1.6-beta1 release, but based on some recent benchmarks it looks like it needs some re-iterating. Alex implemented something called call site caching. Here's what goes on. When we encounter a call site we look at some notes we left the last time we ran through it, (assuming there are any). We compare notes, and if nothing changed, we don't recalculate the MOP dispatch and just do what we did last time. If our notes are different, we do the full MOP dispatch over again. It's the 'memento' design pattern. Charles Oliver Nutter has a great writeup on how this works. I thought it would speed things up, but I was suprised by how much.

Consider these external numbers from The Computer Language Benchmarks Game. Left is the comparison implementation, right is Groovy. White is speed, black is memory consumption. Measures are relative to each other.

First, JRuby 1.1. (Note: JRuby 1.1.1, wasn't on the alioth site)

This surprised me. Charles Oliver Nutter has been working intently on making the JRuby call sites work very well with the HotSpot optimizations. Lots of talk about monomorphic branch paths, reflection barriers, and other stuff that makes my head hurt like I'm back in my undergraduate algorithms class. Groovy beat JRuby in most of the tests (it used to be all but one, but it looks like possibly it got the JRuby 1.1.1 update). I'm not sure why however. Possibly better loop optimizations.

I remember that Charles was excited that some JRuby benchmarks had been running faster than Ruby, and that it was running Rails faster, some I compared Groovy against Ruby 1.8.6.

The first two places Ruby beast groovy are not surprising, calculating the digits of Pi and regular expression searching of DNA sequences. The last on we get spanked on, printing hello world. This is partly because the way the test is set up groovy both compiles and executes the test, then there is plain old jvm startup time, even plain old Java loses to Ruby in that one. There is also the issue of memory consumption. Generally speaking Ruby has a better story when it comes to these benchmarks.

Ruby gains some ground when using the YARV vm in Ruby 1.9, but Groovy still maintains a performance edge, while getting beat on memory for the most part.

Now I am not claiming that Groovy is the most performant language on the JVM, it isn't. But it's performance story has improved markedly. Since groovyc can jointly compile plain old java (which is slightly faster than Scala) it provides a nice fallback for performance intensive parts that are critical.

Now it's time to pack for JavaOne.

Update: Some of the analysis is off because some of the groovy programs that are missing are being filled in as time goes on. Some of these are as partial sums and reverse complement (which Groovy stinks at apparently) and more (like k-nucleotide) are to come. I am also directly linking to their images, so as the other implemetnations get updated, the images will change.

May 13, 2008

Greet - A Groovy Twitter Client

The demo application from the Groovy SwingBuilder Tech Session at JavaOne 2008 is now runnable via WebStart. (note to self, link to SDN site when the presentaiton goes live). The source code may also be browsed via FishEye. There are a couple of points I wish to call out that were touched on in the tech session:

Model View Controller Separation

The GUI has a firm model view controller separation. All of the Twitter API functionality is sequestered into the TwitterAPI.groovy class. No other class does network functionality. The GUI code is also handled separate from the controller. View.groovy is the main class, whereas a couple other classes (ScrollablePanel.groovy, RoundedPanel.groovy) are there to support the view portion. One other view class, TweetLine.groovy, handles the rendering of the individual tweet line (because I was not satisfied with JList). Finally there is the controller class, Greet.groovy. In addition to the main method all Swing events are dispatched to the various controller methods. State variables are also kept here.

Use of @Bindable and bind()

A lot of the glue code to manage visual state with the controller has been automated because of the new @Bindable annotation in Groovy 1.6. This allows me to send notices that the view shouldn't be accepting updates and also notify the view that the backing data model has changed. Adding these hooks by hand would add at least 100-200 lines to the application and would also introduce repetitive code that is prone to cut and paste errors. The view code uses the bind() node to easily bind the values of the actions to relevant attributes.

Actions are your friends

Less of a Groovy call out and more of a Swing call out. Use actions, actions are your friends. All of the buttons, text lines, and list boxes are not hooked directly to the controller, but to the action. This causes all of the relevant controls to turn off when the action becomes unavailable, and is why the bind to enable occurs in the actions definition and not the control definitions.

Builder scripts are still Groovy Code

In line 142 to 147 of View.groovy I do a loop inside of a panel to add the tweet lines individually, calling out to the TweetLine.groovy script. This is perfectly legal in Groovy, since a builder is actually just executing closures and using meta-programming to intercept the method calls. It may look like a static declarative XML type file in most cases, but it doesn't have to. Especially with repeating elements, it's a great way to DRY out code.

The 'Dynamic Language' part is what makes it possible

The dynamic language aspect of Groovy code (and in particular the Scripts) is what allows for most of the magic to happen. It is essential to the builder pattern. You will also notice that both of the principal view scripts (View and TweetLine) don't create a SwingBuilder, or even imply that one exists. They also use variables that are not defined in the scope of their script (like the controller object and the tweet). This provides for a very subtle form of resource injection that requires no ceremony to access. If this were statically typed I would have to state somehow the methods and fields the controller and tweet have, even if by simple type decleration. All of that formality is unneeded in this context.

So what is the future of Greet? I intend it to be one of a few marquee examples for a project I am attempting to get off of the ground with a few others, so the WebStart version may see some changes every once in a while. But that is also why I am a fan of the promise of WebStart (if not particular shipped versions), new versions can be distributed without the same ceremony as an installer.

About May 2008

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in May 2008. They are listed from oldest to newest.

April 2008 is the previous archive.

June 2008 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33