Is Groovy 60 Times Slower than Java?

Tiago's analysis is additional evidence that Groovy is still heavily broken performance-wise. This is not defensible with productivity vs. performance arguments, simply because there are other languages with similar features - MOP, dynamic typing etc. - that perform much better. Including JRuby, which allows an apples-to-apples comparison as it shares the same runtime. And JRuby faces some additional challenges, because the Ruby language is full of bad design choices that impact performance heavily without any good excuse (Charles Nutter blogged extensively over these issues, here for example).

Yes I can put up with a language that is slow because it has some features that I want, and consider more important than some performance disadvantage that is an intrinsice cost of those features uner current compiler/runtime technology. But a very different thing is accepting massive performance disadvantage that's mostly related to a weak implementation. Would anybody, these days, use Java if it had mediocre GC performance, now that advanced GC implementations are available (and even a commodity)? Not me, that's for sure.

Fact is, Groovy is pig slow because it goes through ten layers of dynamic and meta stuff every time you attempt to add two integers. This is absurd. Any competitive dynamic language needs a compiler/runtime that's smart enough to remove most of this overhead (e.g. with type inference).

I really have to agree with you on this point, Francis. There are lots of scenarios where one product/language/platform is faster than another, but both are more than adequate to get the job done well. It is way too easy to get sucked into comparing big tables of numbers and forget that the human differences may still be negligible. Fast enough is, well...fast enough!

Artur! You're coming at me so strong!? Easy there! I'm not playing a game, and Tiago isn't stupid. Be kind to the guy, for goodness sake.

This is a friendly dialogue about one developer's attempt to zero in on performance issues to see if he could make significant improvements. He documents some ways in which he has achieved material gains, acknowledges that he can alway just use Java in the critical areas, and is fundamentally friendly (if not plainly self-effacing) and informative about his process and the details of his attempts. Why attack this? I don't get it.

(Maybe it's just late, and I am in an easygoing, friendly mood. I don't wanna get in some silly argument, but I'd be delighted to hear how further improvements could be made to speed up Tiago's tests.)

Rick

PS - I'd be willing to bet that we could find someone not so many years ago who posted similarly strong statements about how Java wouldn't and couldn't ever reach acceptable performance levels. Never is a long time, so I wouldn't count Groovy out.

If I wanted to create a database driven, template processing, content management system, and deploy it on a Linux virtual dedicated hosting solution (gives you a linux root online for about $20, run your own name server, apache, mail server, firewall, and whatever you want), then I wouldn't consider using Groovy. I've created twice, a content management system in Java, and the performance was not bad. But if the general flow of the system would run 60 times slower, I really don't think I could put any load on this thing whatsoever.

To get the performance up, isn't it possible that Groovy tries to compile code without all the method calls and introspection, if it knows what you're doing? Perhaps (re)compile things at runtime. For instance, when a method is called and the parameters passed in are all Integers and all the elements inside the methods are known, it could compile an alternative version of that method that it can quickly jump to the next time that method is called with those same parameter types. That code could be cached of course.

Anyway, my standpoint is that unless Groovy makes a serious commitment towards performance, other than just tweaks, I can't use it.

You're a gentleman and a scholar, Artur! I will gladly admit that there's some ambiguity and a bit of confusion present. In truth, I hadn't keyed in on the assembly language statement at first, and I agree with you that better arguments could be found :)

IMO, Tiago was trying to just share notes about his own efforts to find an answer to this question of Groovy's relative performance. In a way, I felt it was more a "thinking our load" and letting the public peek into his notes than an attempt to assert anything conclusively. Tiago seems to be looking for insights that help him better understand the issue and construct reasonable, thoughtful comparison code. 

I didn't really sense him taking a position or setting out to "prove" a pre-determined conclusion. Instead, I really felt he was trying to sort it out to gain an understanding of what conclusions might be supported by what evidence. Instead of a thesis, I think we're seeing something more like lab notes.

Rick

Whic is why we in the Groovy community support both Groovy & Java in the same project, we are not trying to replace Java, we are enhancing it. You will see some core components of Grails written in Java and not Groovy for the same reason. If speed and performance is required then drop to Java, if it really is a killer requirement, drop to C. Go to assembler to revive fond memories and have oodles of fun.