—

Groovy vs…

I have been a bit surprised at how often Groovy performance is compared to Java. That’s just not a comparison that ever occurs to me. I wouldn’t expect Groovy to compete with Java itself, that seems silly. However, I would like it to compete, not win just compete, with other “scripting” options out there. Almost exclusively what I care about is how Groovy compares to Perl, Python, and Ruby (and not JRuby, etc.), because those are the languages my colleagues use, and those are the things they are going to compare Groovy to. If I hand them a Groovy script, and they run it, and it’s obviously abysmal, I loose credibility, which is very expensive in my profession. “James is that flake who uses that dog slow Groovy”. A lot of people sound like they don’t have to deal with these kinds of pressures, but really it’s exactly this that makes me deeply care about Groovy performance. I have to be able to give Groovy scripts to my peers with a straight face.

I just mention this because for me Groovy primarily serves the same role as Perl, Python, and Ruby. I prefer it over these others because I write a lot of Java code too, and I like to be able to tap into that now and then in the very transparent way that Groovy lets me, as well as the rich set of Java libraries out there. But by and large, when I’m writing a “script” I want to stay in “script world” and not jump out into the world of compiled applications. So it’s important to me that my “scripting language” be able to accomplish a fair amount of work on it’s own.

To this end, I have seen on the developer’s mailing list archive [1] a nice suggestion. The idea is to allow Java to be mixed into Groovy in a source file and compiled by the runtime compiler, so that you can run a mixed Java/Groovy text file seamlessly as a single script. That would be great for me. Then I can stay in the world of “open a text file, bang out a little program, hand it to someone” that makes up the “scripting” half of my life, but be able to tap into Java without having to completely drop out of “single file script world” and into the world of compiling and packaging jar files, etc.

Perhaps all my whining about not wanting to compile things sounds like… well, whining. But Groovy is about convenience for me. It’s useful to me precisely because I can hack out little fifty line programs in a single file and then just run the thing. The second that becomes two twenty five line files, with products I have to package, Groovy looses more than half it’s utility to me.

Anyway, I just wanted to mention it here in the slight hope that some momentum will build behind the mixed-Java Groovy runtime compiling. I believe it would be fairly easy to implement and it would go a very long way towards answering my own issues with Groovy performance.

[1]

http://archive.groovy.codehaus.org/dev/197b18fc0802210742y4b943e6budcaa64af3791f899%40mail.gmail.com

Despite comments from several posters, that performance isn’t important, it is. Everyone likes a snappy application. Lack of snappiness is one reason Java failed to become anyone’s GUI of choice. Sun’s server-side corporate group-think never grasped this.

Think of the top 10 to 20 most popular GUI applications used by non developers. After 10+ years of Java, only a small fraction of them are written in Java. Groovy will fail too if it isn’t snappy and competitive in performance.

Twice before I’ve tried to get into Groovy as a command-line scripting language alternative to bash, Ruby, and Python. Each time Groovy’s sluggish performance made me stop using it. As of now, it can’t compete on the command-line with its peers.

A slow performing language, compared to it’s other dynamic language peers, will in my opinion, remain a toy, hobby only language. That’s not the kind of language I want to invest my time learning.

So I’m pleased to hear that Groovy developers do value performance and are working on this issue. (Thank you Groovy devs! )

Now I’d like to comment on the emotional undertone of some comments above. I feel that Daniel Spiewak has done Groovy a service with his blog about its performance. To me Spiewak doesn’t come off as an overly biased proponent of another language out to slam Groovy. Yet, that is the feeling I get when reading Graeme Rocher’s comments to Spiewak.

Attacking Groovy critics is unwise and will drive away people considering the language. Nobody wants to be part of a community of mean spirited people. It’s one reason for Microsoft’s lack of popularity with many developers.

Groovy is in a difficult competition for developer hearts and minds with J/Ruby, J/Python, PHP, and Scala (and more language choices appear all the time). I suggest that if Rocher has a hard time welcoming and engaging Groovy critics in a positive way, especially thoughtful ones like Spiewak, then he should allow other Groovy community members, with better PR and relating skills, to do it instead.

“The Groovy 1.5.4 stable release is the latest release. No milestone releases for the next version of Groovy have yet been released.” http://groovy.codehaus.org/Download

The ‘-server’ tag /is used/ for the benchmarks game measurements.

I guess I can do that by continuing to drop Java .jar files into the groovy lib directory for my internal customers, and package up a .jar for external customers. So maybe I’m fretting overmuch about a small thing. I’m just hyper sensitive to the anti-Java skepticism of my colleagues, so I’m always trying to minimize the perceived difference in usability.

James

Since you already have to package your Java application to look like a normal command line app, Groovy really isn’t going to add to that overhead. I assume you’re either using a wrapper script or cross-compilation (using GCJ or similar). With the wrapper, you can just add Groovy to whatever you’re already doing for packaging and things should work perfectly. If you’re cross-compiling, things get a little hairier, but not too much so. The Groovy compiler produces bytecode, so GCJ should be able to consume that as easily as it does any regular Java artifact.

Why not make it a jar file? Well, that should be a perfectly reasonable option, but alas the world isn’t perfectly reasonable. My colleagues and clients and, importantly, bosses, are often biologists who know some Perl but not much more. For reasons that are obscure to me, Java has gotten a bad reputation among this group. The biologists who write the checks just want to get a paper out about the genetic causes of epilepsy or something, and so they don’t care about the software at all, per se, just the final result. I’m just guessing, but I expect that Java got a bad rap among this group because Java programmers tended to over engineer their assignments. Whatever the case, I’m always fighting an uphill battle to use non-Perl or non-C tools. So, as much as possible, I’d prefer not to draw attention to the fact that I’m using Java based technology. I’d really rather not remind them of the fact every time they run James’ software. “Oh, great, it’s one of Jame’s jar files… how do I run that again?” I’d like to be able to give them a file that they just run like they are used to, like a Perl, Python, Ruby, or even C program. You want something to find splice sites? Sure, here it is:

findSpliceSites input.fa splice.out

It’s all a bit silly, I know. I mean, I REALLY know. I have to live with Ph.D’s who act as though remembering to do “java -jar” to run a jar file will overtax their abilities. It’s a bit absurd and very frustrating, but no less real for that. I strongly suspect that I’m not the only person who works in an environment where Java’s clunky command line packaging is a liability. One of my hopes for Groovy was to smooth over this prejudice, to write little Groovy-only scripts for a lot of the little programs I have to generate every day. That’ll only work, though, if the Groovy script isn’t grossly slower than they are expecting.

Also, if you prefer just to give folks one file, why not make it a .jar with combined Java and Groovy?

For instance,
“groovy -server ray 8 64″ takes 43.859s (About 100 times slower than Java on my system)
“groovy ray 8 64″ takes 115.735s

In the binartrees test,
“groovy -server binarytrees 16″ takes 41.047s
“groovy binarytrees 16″ takes 126.000s
Ruby 1.9: “ruby binarytrees.rb 16″ 55.891s
JRuby 1.1: “jruby binarytrees.rb 16″ takes 60.184s
JRuby 1.1: “jruby -J-server binarytrees.rb 16″ takes 33.047s

I’ve got a zillion benchmarks on my system, because certain bloggers had me convinced it was unusably slow, and so wasn’t suitable for production Fortunately I bothered to run some tests on my own, and found out otherwise.

From the looks of things, Groovy 1.6 just may beat out JRuby 1.1 as the fastest dynamic language which integrates easily with Java.

I work in bioinformatics where Perl is king. Perl works well but I hate Perl. Every night I pray to the language gods that I will never have to write another line of Perl. Since I’m fairly fond of Java Groovy looked like the answer to my prayer. It really is the ideal language for my purposes except…. it’s dog slow. I could, and still might, learn Python or Ruby as a replacement for Perl, but now that I’ve seen Groovy I really don’t want to. I want Groovy to work for me. I want the Groovish syntax, and I want to be able to seamlessly leverage all the Java libraries out there, including my own Java code base. All of the dynamic scripting languages are, of course, slow compared to C or even Java, and that’s fine. But for me, the standard for an acceptable scripting language is Perl. I can use a language that is 2x or maybe even 3x slower than Perl on tasks I commonly perform, but I can’t use a language that is 10x or 20x slower than Perl. The data I operate on varies from a few mega-bytes to a few gigabytes. It’s a tremendous difference in the amount of work I can get done if it takes 10 minutes instead of 30 seconds to process one data file.

Speed is not just about the actual time it takes to do something, though. It’s also sociological. It is hard enough to convince colleagues, who are used to running Perl programs or C programs, to even accept something written in an obscure language with a cute name like Groovy. It becomes impossible if the script you give them also runs obviously, and glaringly, slow. If you try to remedy this by sending along some Java classes to do the heavy lifting, then you enter packaging hell. I really want to hand people a single file to solve their problem. Or rather, that’s what my customers, other scientists, demand of me.

It is, of course, one of the best features of Groovy that it’s not just easy, but totally transparent, to mix in Java classes, and in practice I do that a lot. But very quickly it ceases to be a Groovy program in any meaningful sense. I start to feel silly even using Groovy when all my Groovy script does is create a series of Java objects and invoke Java methods on those objects.

I find it hopeful that the performance of Groovy seems to vary wildly between different tasks. That makes me think it has some quirky bottlenecks that can be ironed out. For example, on the computer language shootout… er… benchmarks game [1], I was able to write the regex-dna benchmark so that it took 15 seconds, which compares well enough for me with Python’s 6 seconds, or Ruby’s 7 seconds. However, I was unable to come up with a Groovy implementation of the reverse-complement benchmark that was anywhere in the ball park of being competitive (the one someone else submitted is 9000x slower than Perl !! I can beat that, but all my efforts have been too poor still to bother submitting). These tasks, regex-dna, reverse-complement, k-nucleotide, are not just arbitrary benchmarks to me either. These represent very good approximations of the bread and butter of my daily work.

I’m not commenting to rag on the Groovy developers. I’m a big Groovy fan. I want to make Groovy the next bioinformatics language of choice. I am, moreover, very impressed with what the Groovy team has done so far and rather quickly. I just want to add my voice to the chorus saying, “Performance matters, it matters a lot, and even us fanatics can’t ignore it”. I want to do whatever I can to put performance on the front burner of their future efforts.

[1] http://shootout.alioth.debian.org/gp4sandbox/