http://railsexpress.de/blog/articles/2007/09/18/rails-edge-performance

The fact that every version of Rails has been slower than the version before it is Not a Good Thing. Consider also the equally disturbing statistics about the interpreter it’s built upon:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Second slowest of all languages when everything is considered. And about twice as slow as PHP. Again, Not a Good Thing.

Mind you, I want Rails to succeed as much as anybody — I’m half way through programming a web site that is written in RoR. But it doesn’t give me a warm fuzzy feeling to hear DHH and the Rails community marginalize the problem, saying it is 1% of websites that need speed, or saying that we save developer cycles so who cares about performance or saying we can write things in C.

The truth is, regardless of your needs, a naturally fast framework is a framework that allows programmers to spend time programming instead of spending time understanding advanced caching techniques and multi-database transactions. I love how powerful RoR makes me as a developer, but as long as DHH & others continue to label performance as “not important to improve,” Rails runs the risk of being supplanted by something uglier but more practical.

Also, I think Rob’s point was more about the attitude of the Rails team than it was about performance. If they tell you to piss off on something as important as scalability, then it is sure to affect other parts of the platform and community. This is just a symptom of a larger problem. To me this is the equivalent of the “Runs on My Machine” mentality.

It’s not Ruby’s performance. It’s Rails’ performance. It’s important to be clear about that. Ruby isn’t that fast, but it isn’t that slow either. The Ruby I write today is routinely faster than the c# I wrote in the past. First, not everything in Ruby is slower: Regexps are much much faster in Ruby, so parsing routines are much simpler/faster. Second, it’s much easier to change directions with a design in Ruby, and it’s those sorts of changes that give you orders of magnitude more performance. C extensions for more performance are 1 in a million situations.

@Eber,

100 lines of code is a very local optimization. You’re right about not falling back to C in .NET. Which means when you have a performance problem in .NET, it’s more than likely a fundamental design flaw and 100 lines of anything aren’t going to fix it. It’s much easier to re-mold a design into a performant image in Ruby, which is where all the big wins are anyways.

@Avery,

You aren’t the only one, so no offense. But where is everyone getting the impression optimizing Twitter was easy? In the scaling Twitter presentation it certainly didn’t look easy. They threw out abstractions every step of the way and went with denormalization, and lots of custom SQL to the point of basically using ActiveRecord as a fancy version of ADO.

They ripped out RJS as well, but frankly I think people need to just learn JavaScript anyways, so serves ‘em right.

Oh, and everyone talks about shard-ing Twitter’s databases as a solution. That’s crazy-talk to me. 600rps is not enough to take on all the pain of splitting your database out into read-only slaves and a write-only master. It’s a nightmare! That people seem to accept that as a legitimate solution (that last I heard Twitter hadn’t actually implemented yet) is just… insane frankly.

No… it wasn’t easy, and it wasn’t right. It’s easy for me to arm-chair quarter-back, but it’s a pretty safe bet that projects like Merb and DataMapper could have let them keep 90% of Rails goodness, leave out the 10% bad, and stand a good chance of doubling (or more!) performance in the process.

Rails isn’t the only game in town, and it’s certainly not the best Ruby has to offer. It’s beautiful sure, and the alternatives would do well to ape most of it’s API, but the implementation is… lacking. Plus DHH is an egomaniac. Ezra (author: Merb) manages to be nice and soliciting of community feedback while kicking Rails’ arse in the performance game at the same time.

Rob,
I agree with you that from a community perspective they would be better off paying more attention to the performance issues, but I really don’t think there is a performance issue for 99% of applications and so I think it’s being blown out of proportion.

CD Baby doesn’t surprise me because I see projects fail all the time, it is rarely a technology issue. Look at Twitter, it has all kinds of problems but is insanely successful.

I agree that there are some problems, and I would hate to see it turn into ego wars. But I don’t think those problems are much worse than any other technology.

One day I hope we are working on a rails app together.

RE CD Baby – come on. It’s a commerce store front. Are you telling me that a 2-year rewrite, which amounted to nothing, is meaningless to you?

Finally – I love Rails, as I mention twice in my intro. I want to see it mature into the platform it should become without falling into ego wars.

Imagine if I told the SubSonic community “perf is your problem”. I’d be hung from the highest tree possible.

It IS very likely that the rails team finishes first, captures the market, creates a huge user base that you will find difficult to convert…

Basically whoever gets there wins, provided your app doesn’t suck. Twitter is in a good place. They proved that they have a niche market that can be successful. Now they have to deal with there problems, and it doesn’t mean “rewrite it in php” because you’ll face similar issues.

Anyway back to our team. Google buys team 1 (ror) and the original guys retire in the south of France drinking wine and eating cheese.

And I’d also like to comment that it only takes 1 or 2 really smart people to write the critical sections of code in assembly or C for major projects, and everyone else can just benefit. Can’t write an algorithm in C?

Go back to school or hire someone who can.

Knowing a little C is easy, it’s not like they are rewriting the framework in C. You could always pay someone to write the 100 lines anyway.

C extensions in .NET are not* required, you can’t even compare Ruby vs .NET in terms of performance

Great, now you have two problems.