May we have Ruby and Rails performance statistics? We're persuading the business to use Rails!

Question

We're convincing our Products officer that we want to use JRuby on Rails, and we're having a hard time coming up with some statistics which show that:

1. Coding time is less using Rails vs. say Struts or Zend Framework or what have you.
2. Ruby (and JRuby in particular) performance isn't horrible (anymore).
3. Rails performance isn't bad either.

If you can get us some good stats quickly, we might have a chance!

Update:

We actually did convince the business to use JRuby on Rails, and we're a few months into the project now. Thanks for your help!

Answer 1

Pretty hard question to provide concrete information. Performance really depends on your app's use-cases and architecture.

I would suggest you whip up different versions of a particular use-case and measure performance. It could be a quite simple view that hits the database and renders the page. Use the same DB structure.

The irony of the whole argument is that PHP isn't the fastest thing on the block either. In non-trivial apps you need to start adding an Accelerator to cache your bytecode. The JVM has incredibly advanced support for this kind of stuff. The Rails architecture, being based on an app-server approach gets around a lot of this because you actually have an application-wide memory scope (PHP needs to parse and render everything on each pass).

Anyway, from my own experience, I have used PHP since 2000, moved to Rails several years ago back in the pre-v1.0 days) and have large systems in production using both.

• I have found that Rails is much faster to develop in. I have found it up to 50% more efficient, depending on the feature. As in, I can develop in half the time.
• I have production Rails systems with heavy database usage that render in 200-300ms.
• The Rails ecosystem is these days much further ahead of PHP when it comes to support for all of the ancillary systems and processes required for good software engineering. There is no coincidence that libraries like Cucumber and rSpec have evolved in the Ruby world.

Answer 2

It's hard to quantify 1 even when it's clearly true. A poor measure but the best I can come up with is the comparative gzipped size of the code:

http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=yarv&lang2=java

The ruby code contains half the "information" of the Java code. I've done a few years of rails, and plenty of other frameworks, but it's near impossible to quantify, since I've never written the same project in two languages/frameworks.

The one thing that isn't accounted for in the graph though is that Ruby can't have compiler time checking, so you generally have to have better test coverage in order to have confidence in the code you're deploying.

1. Ruby performance has come leaps and bounds in terms of performance. It's still bad when you compare it to just about anything, but for a web front end, it honestly doesn't matter that much. JRuby is faster than Ruby (1.8.x) but still an order of magnitude away from a statically typed JVM language (scala/java etc).

2. Honestly, Rails is damn slow for a framework. The computational heaviness helps allow an insane rate of development though. For a front end, it doesn't really matter that much either.

Your front end framework/language choice is only going to add maybe 10s of milliseconds to each request. If you your app does anything significant with data at all, the front end presentation/calls aren't going to take the majority of the request time.

It's pretty much all about trade offs and what does/doesn't matter. Computational speed of your front end language honestly isn't that important, and the productivity boost of a "slower" language such as ruby generally outweighs the things you give up.

Answer 3

If you want to bet PHP code by Rails in terms of raw speed, forget it.

Business decision concerns more than raw script speed, namely:

• interoperability, how well your new app will fit in the corporate app environment
• continuity, how many other staff knows (adopts) rails like you and how likely you can recruit more if there is none, what if you are gone, say, 3 months later?
• security, more than how secure rails is, also concerns how fast any issues can be fixed, who will fix that
• reliability, recovery .. etc.

and you have more to concern:

• deployment, mod_rails is here, but it's still not straight forward as php, you have need admin team's commitment
• scalability, probably won't be concern, when you have as much traffic as tweetie, you will get the budget to rebuild it ;-)

we know we all love rails. many still don't. let's go preaching ;-)

Answer 4

Well, there are Lies, damned lies, and statistics.

The problem with your question, is that it's neigh impossible to answer out of context. Ruby is generally not a particular fast language, but it totally depends on what you are doing. Why do you want to use speed as a measure of quality? Is your application doing something that is very resource intensive?

Regarding development time, I would say that Rails is a proven stack for rapid development. But so is PHP. Which is the better choice, depends a lot on the programmers.