This is a real question, I’d like to hear your opinion on this matter.
Ruby is known to be slow, even compared to other interpreted languages like python. It’s sad, but it’s true. Does it bother you? Well, don’t be shy, i’ll answer first : it bothers me. You probably heard of the recent twitter performance issues. Well, it appears that ruby is partly blamed for this. Of course, there are probably some implementation details that could be improved in this application (just speculating here) and Rails itself should also take a good part of the blame (e.g. some ActiveRecord features are known to be costly on the performance side of things). But for now let’s forget about Rails costly features and let’s focus on the programming language behind it.
We cannot hide behind hardware-is-becoming-so-performant-and-cheap-that-it-doesnt-matter kind of excuses anymore. While it’s true that buying better and faster hardware will mask the fact that ruby is inefficient, it seems like we’re just trying to put a plaster on the real problem. Ruby performance shortcomings must be addressed at it’s heart, that is, in the source code of it’s official interpreter.
Could YARV be the saving grace?
What is YARV? YARV is another virtual machine for Ruby like are JRuby, Rubinus and the official interpreter written in C (ruby 1.8). In other words, it’s simply another implementation of the programming language we love. YARV humorously stands for Yet Another Ruby VM. The smart guy behind this project is SASADA Koichi and his goal with YARV is crystal clear. Like he said : The goal of this project is only one, to develop the fastest Virtual Machine for Ruby in the world.
Is it faster than, say, JRuby? I don’t know, but I know what I like the most about it : YARV is expected to get merged into the official implementation of the language. What does it means? It means we would still be able to call ourselves rubyists and not yarvers (phew). Big deal huh? This detail aside, I think it is quite important that the official interpreter stops being qualified as the worst of all. For a lot of people (myself included), the official ruby interpreter IS ruby (we can hardly blame us for wanting to use “the real thing”, can we?). To me, the importance of having an official virtual machine that is efficient is crucial.
Now, I have two questions for you :
- Are you concerned about ruby being slow?
- Do you have faith in YARV?
14 thoughts on “Are you concerned about ruby being slow?”
First, let me say that I’m a long time DotNet and MS technologies programmer. I am also looking at RaR, with a couple other guys who are more proficient with it, for a potential startup project that we’re looking at doing. To say that I’m not troubled by the decision would be an understatement. About half of that is performance related worries, the other half is a distinct dislike of Ruby syntax.
Furthermore, C# on .NET has available similar libraries to take a lot of the pain out of the programming, jut like Rails does. I’m personally most familiar with a framework called Gentle which is an ORM that I’ve written extensions to to make it more “rails like” and take some of the grunt work out of building an application. It still needs a lot of work, and the Gentle project appears nearly dead due to lack of support, further vexing my decision…
The other two guys are NOT MS types, so I can completely understand them not wanting to do the investment needed to get into .NET. So, I am at a sort of cross roads of decisions, and I’m not comfortable with any answer.
I don’t know enough about YARV to make any claims of faith. I assume that most languages and technologies can be made to perform better, if enough effort it put into them.
I thought… and I could well be completely wrong about this… that the new ruby 2.0 interpreter that matz and crew are working on is meant to be *much* faster. Like I say I could be wrong about that but from my various readings over the last year or so that is the impression I get.
I certainly agree that ruby is slow compared with other interpreted languages, but I think it is probably only a real-world issue in Rails apps for those people running seriously busy sites… again I could be wrong… ;o) wouldn’t be the first or last time! ;o)
That’s interesting. I have build web applications in .NET (VB) for the last 4 years. Even though I recognize that .NET is a powerful platform, I find that Rails is so much better. This last comment should be taken with a grain of salt however… since I only worked with version 1.1. I heard things have changed a little since then 🙂 But, it’s like I’ m just fed up with .NET. My last full year as a .NET developer bored me to death, I swear. When I decided to try RoR, it was like my saving grace.
Never heard about that Gentle framework. If it helps building .NET applications faster than it’s good news.
Well, if Ruby 2.0 becomes much faster like you said, it will be in part because of YARV which is planned to be integrated in this version.
I don’t think presenting Twitter as a model of Ruby scaling is at all valid.
First, are you talking about Ruby or are you talking about Ruby on Rails? Two very separate things.
Ruby, like you say, is slower than Python. Whether this will still be true when Yarv comes along we don’t know. Either way, I say it doesn’t matter. It doesn’t matter because the vast majority of a program isn’t all that affected by computation speed, especially when talking about a web application. Not only that, but if your program is sluggish, you can easily profile your application and, if it’s not possible to optimize it more, replace the bottleneck entirely with C. It’s actually very easy to do in Ruby.
Now for Rails. The twitter case I’m not really happy about people using as an example of scalability. First off, they can get up to 12,000 hits/second. That’s a massive amount of traffic. Their first bottleneck was computational but when they added more mongrel servers, this bottleneck was resolved. Their complaint is that it’s difficult to connect one application to multiple databases with Rails. As DHH pointed out, this is true of any single-stack framework. This however, has nothing to do with the speed of Ruby. Twitter’s bottleneck is the database connection. Changing to Yarv, even if Yarv is two, three or 100 times faster will do nothing for them since it won’t affect their bottleneck. They might be able to run less mongrel servers but overall there will be no change. So really it’s a Rails framework problem (the ability to easily connect to multiple database), not a Ruby problem.
And when thinking about whether you should adopt RoR or not based on scalability issues, consider when you’ll be getting to 12,000 hits/second and whether by then the ability to connect to multiple databases will be included in Rails, either because the Twitter guys figured it out and published how or someone else did. Even the twitter guys didn’t say it’s impossible. I’ve never tried so I don’t know myself. They just said it’s not as easy as everything else in Rails and that’s why they were complaining.
1) Are you concerned about ruby being slow?
Short answer: no. Machines are cheaper than people.
2) Do you have faith in YARV?
Again, no, because I don’t think Ruby’s performance is what’s holding it back — people’s *concern* over Ruby’s performance is. Twitter’s problems (11,000+ reqs/sec) are in a realm beyond what most of us will deal with, but my $JOB’s primary application is written in Rails, and supports 200 employees and 7000-8000 users on one server. Adding another server is as easy as setting up the new box and adding a line to my proxy balancer config.
Selling Ruby and Rails as a platform to mgmt was much, much harder than implementing it.
I’m as worried about Ruby’s performance versus Python as I am about C’s performance versus hand-written assembler. That is, not at all. There are some people in this world who live for benchmark numbers, and some of us who are pragmatic and live for actual results.
I’ve ported Perl scripts to Ruby which have then been significantly faster on Ruby, not because the language is faster but because the libraries used have been better written, have used C extensions, and any number of factors. A great coder in Ruby will kick an average Python programmer in the ass, so it’s not always down to the speed of the language but the programmer.
One great example of this is in the land of SQL. It seems most developers have only a basic knowledge of SQL (particularly people who write forum software for some reason..) and design some absolutely hideous databases and queries and expect the RDBMS to sort it all out (which it doesn’t). It’s not rare for a semi-competent SQL developer’s code to outperform crappy SQL code by 10 to 100 times or more, simply because they know what they’re doing and can compress an operation into, say, 10 rapid database operations rather than 1 humongous join that takes five minutes to run.
So.. more Ruby performance is always a good thing, but more important is skill, understanding algorithms, and being able to see the big picture of optimization rather than the raw speed of the language.
If you threw me in a Formula 1 car, I bet I’d still drive like crap, and Michael Schumacher could probably beat me in a Mercedes SL no troubles. It’s the skill, not the tool.
1) Yes, I am very concerned. Some of us want to bring Game Programming to Ruby and for that we need a fast interpreter.
2) Yes I have faith in YARV. I have to have faith in it :).
Maybe actual numbers will be more useful than guessing? . Should be a few more articles on eigenclass on the topic iirc. You can try also Rails on YARV for yourself, btw…
comment form stole my link! : )
it seems that YARV is good enough
I had read this article a while ago, comparing the different VMs.
He hasn’t run the 2nd batch of tests like h said, but it’ll be interesting to see those results too.
I’ll be at RailsConf ’07 and I’ll have to say, this session:
on scaling Rails apps on Amazon’s EC2 service has me quite excited.
1. yes, I’m concerned about it. but what I concerned more is the fact that ruby’s thread is plain suck, is modern age already, why still use process. I also disagree with DHH argument in this case, process does indeed easier to manage in code, because actually nothing to manage, but thread is more powerful because it is (quite) dangerous (code & var sharing). I hope YARV will fix it
2. I’ve said it in my answer to the 1st question, yes I have (quite) high hope for YARV. but does anyone know about the progress of the project ??
I am not worried about speed. I believe the Ruby development team will take Ruby to the next level regardless of whether YARV is used or not.
Connecting to multiple databases has been sorted out.
Nearly all of the patches include Fucus Vesiculous (a remove of
sea kelp). I simply replaced a few cups of this tea every day instead of the coffee
I consume in the past. Follow this dosing schedule for the first week.