Performance: Groovy/Grails vs. Ruby/Rails?
So, in the comment thread that followed: The Pain of Java after Ruby, I off-handedly commented that I'd been given the impression that Groovy or Grails' performance was worse than that of Ruby or Rails. I was inevitably challenged on that point.
Let me back up a little and cover some of the ground I covered in that comment: I haven't attempted to benchmark Groovy and/or Grails at all; Grails didn't have great support for REST services when I last looked at it, so I didn't include it in some of my performance explorations at the time. We were able to get 600 requests per second from Restlet, and were able to get something on the order of 40 requests per second on the same hardware using Ruby on Rails. I'm sure both of those results could be improved upon. (At the time, JRuby was scoring about 28 requests per second; I gather performance has improved since then).
So, it begs the question: Does Groovy and/or Grails outperform Ruby and/or Rails? You'd certainly like to think so, given the Java VM underneath it, but what have people said?
Well, the Grails folks would probably argue that their solution performs better although it's still clearly a tight race. There's a little grumbling from some people with more Rails expertise, but there doesn't seem to be any outright disagreements.
That said, if you compare either of those solutions back to a Java equivalent, the results are usually pretty striking. There's a few examples of that out there.
So for now, I'll say that it seems like Groovy may have the edge on performance compared to Ruby, although it's still very much a two-horse race, and both have many further opportunities to gain ground.
However, it's also clear that both of these two solutions are, in the overall spectrum of development platforms, relatively slow. Depending on what you're building, that may not be a big deal, but it can certainly be a concern.
Labels:
development,
grails,
groovy,
java,
performance,
rails,
ruby,
software
6 comments:
>>Depending on what you're building
>> that may not be a big deal
I think that's the key point.
The ray tracer example is somewhat irrelevant, other than for interest sake. But who would use a scripting language for such a thing? While I may eat those words some day ("who would write a game in Java"), I think it's a valid point of view right now.
Even still, I'm admittedly a bit disappinted with Groovy's performance there -- seconds to hours is never good. But it likely won't affect web app performance in any relevant way.
Any volunteers with time to write that in Ruby for fun?
Cheers,
Clinton
Well, yes and no.
I agree, the ray tracer application is pretty unlikely, but if you're pretty sure your application, if it were coded in Java, were going to require four application servers to meet the load and the response time expectations, it can be pretty scary to imagine that the same load would be met by 60 application servers if you put the thing together in Rails (15x difference on some of our REST tests).
There are, of course, a number of architectural choices you can make to reduce bottlenecks. Caching, for instance. You may have to employ them sooner with a RoR or Groovy application.
Likewise, there are probably many applications out there that don't use anywhere near their hardware allotment, or that are near-I/O-bound, and the performance in these cases might be irrelevant.
Finally, there are cases where performance is important, but not as important as, say, productivity.
As with almost any choice in software development, there are tradeoffs to consider, and performance is only once facet.
I think we're off track. :-) We're talking about Java vs. Groovy in web apps. Forget Ruby and raytracers.
Try your Restlet test with a Groovy version... you can even use Restlet from Groovy if you want.
I guarantee it won't be anywhere near 15x, and your code will be prettier.
Java 600
Ruby 40
Groovy ___?
Clinton
It's true, I can't really comment on Groovy 'til I've spent more time with it. Looking forward to good REST support in Grails so I can give that a shot, but in the meantime, if I can find some time to look at combinations of Groovy with Jersey or Restlet.
I'd certainly be more comfortable having this conversation having done more testing with Groovy, so I'll get back to you. ;)
I think many are missing the point with Groovy completely. Groovy is Java, and works with Java completely interchangeably. So when you're tuning for performance you can switch to Java any time you want. So really Groovy is the best of both worlds. You have productivity comparable with Ruby and you can drop into Java anytime you need heavy-duty performance.
That can also be true for JRuby, although it may be true that Groovy is more-tightly-integrated with Java right now.
While it's definitely a plus, I don't have enough practical experience with mixed Java/Groovy projects to say how often that's necessary. If it's only as necessary as it used to be to drop down to assembly from C -- for specialized routines and identified hot-spots, that may be a compelling approach.
If you find yourself rewriting any stabilized code for performance purposes, then that's less appealing.
Still, that kind of easy-transition polyglot project approach seems both more appealing and less risky than a full-bore dynamic language approach if you or the company you work for comes from a Java background.
Post a Comment