views:

762

answers:

9

I like Ruby on Rails and I use it for all my web development projects. A few years ago there was a lot of talk about Rails being a memory hog and about how it didn't scale very well but these suggestions were put to bed by Gregg Pollack here.

Lately though, I've been hearing people saying that Ruby itself is slow.

  • Why is Ruby considered slow?

I do not find Ruby to be slow but then again, I'm just using it to make simple CRUD apps and company blogs. What sort of projects would I need to be doing before I find Ruby becoming slow? Or is this slowness just something that affects all programming languages?

  • What are your options as a Ruby programmer if you want to deal with this "slowness"?

  • Which version of Ruby would best suit an application like Stack Overflow where speed is critical and traffic is intense?

The questions are subjective, and I realise that architectural setup (EC2 vs standalone servers etc) makes a big difference but I'd like to hear what people think about Ruby being slow.

Finally, I can't find much news on Ruby 2.0 - I take it we're a good few years away from that then?

+1  A: 

Writing code is slow. Reading code is slow. Finding and fixing bugs is slow. Adding features and enhancements is slow. Anything that improves on the previous is a win. Very rarely is execution performance an issue.

GregS
@GregS: execution performance is *always* an issue if it impacts usability. True, scanning an xml file for a string in one second or three doesn't matter from a pure numbers point of view, but a couple seconds difference can make a big difference in usability when you're talking about a user-facing application.
Bryan Oakley
@Bryan: Agreed, but I stand by my "very rarely" qualification.
GregS
+16  A: 

Here's what the creator of Rails, David Heinemeier Hansson has to say:

Rails [Ruby] is for the vast majority of web applications Fast Enough. We got sites doing millions of dynamic page views per day. If you end up being with the Yahoo or Amazon front page, it's unlikely that an off-the-shelve framework in ANY language will do you much good. You'll probably have to roll your own. But sure, I'd like free CPU cycles too. I just happen to care much more about free developer cycles and am willing to trade the former for the latter.

i.e. throwing more hardware or machines at the problem is cheaper than hiring more developers and using a faster, but harder to maintain language. After all, few people write web applications in C.

Ruby 1.9 is a vast improvement over 1.8. The biggest problems with Ruby 1.8 are its interpreted nature (no bytecode, no compilation) and that method calls, one of the most common operations in Ruby, are particularly slow.

It doesn't help that pretty much everything is a method lookup in Ruby - adding two numbers, indexing an array. Where other languages expose hacks (Python's __add__ method, Perl's overload.pm) Ruby does pure OO in all cases, and this can hurt performance if the compiler/interpreter is not clever enough.

If I were writing a popular web application in Ruby, my focus would be on caching. Caching a page reduces the processing time for that page to zero, whatever language you are using. For web applications, database overhead and other I/O begins to matter a lot more than the speed of the language, so I would focus on optimising that.

rjh
"After all, few people write web applications in C." - Of course not, but many performance-critical web-sites moved e.g. to Scala.
Dario
I disagree with the 'throwing more hardware at it' is cheaper. It's hard to convince customers that they should pay more money for hosting every X months because their platform was designed for developers in mind.
Kevin
@Keven: surely development costs would be reduced? Otherwise what would be the point of using Ruby in the first place?
rjh
thanks for the info @rjh - nice answer
stephenmurdoch
@Kevin That statement is a bit broad. If you'd need to set up a new server for every 10% traffic increase or so with some 100 visits per day, the customer would clearly have a right to complain. Realistically though, you usually need to have a lot more traffic to begin with and increase that by an order of magnitude, before the old hardware can't cope anymore. At that point the topic moves into "a good problem to have" territory and hardly anybody would complain about upgrading hardware. Also, no "customer" runs such a high traffic website without being aware of these kinds of things.
deceze
+1  A: 

Ruby is slower than C++ at a number of easily measurable tasks (e.g., doing code that is heavily dependent on floating point). This is not very surprising, but enough justification for some people to say that “Ruby is Slow” without qualification. They don't count the fact that it is far easier and safer to write Ruby code than C++.

The best fix is to use targeted modules written in another language (e.g., C, C++, Fortran) in your Ruby code. Those can do the heavy lifting and your scripts can focus on higher level coordination issues.

Donal Fellows
Comparisons are often made with Java, C#, Python, maybe Perl rather than C++.
rjh
Of course. But I can assure you (as a developer of Tcl) that people will *always* compare you with other languages unfairly. The fix is to use those other languages for components that you stitch together; doing it all in one language is a bit like using a single tool for all tasks. If all you have is a hammer, everything looks like a thumb.
Donal Fellows
nice idea about using foreign language modules when they are needed
stephenmurdoch
>> to say that “Ruby is Slow” without qualification << A couple of years ago they might have gone on to show Ruby programs that were slower than Tcl programs :-)
igouy
You know what they say about Lies, Damned Lies and Benchmarks. ;-)
Donal Fellows
"After all, facts are facts, and although we may quote one to another with a chuckle the words of the Wise Statesman, 'Lies--damned lies--and statistics,' still there are some easy figures the simplest must understand, and the astutest cannot wriggle out of." Leonard Henry Courtney, 1895
igouy
+16  A: 

First of all, slower with respect to what? C? Python? Let's get some numbers at the Computer Language Shootout:

Why is Ruby considered slow?

Depends on whom you ask. You could be told that:

  • Ruby is an interpreted language and interpreted languages will tend to be slower than compiled ones
  • Ruby uses garbage collection (though C#, which also uses garbage collection, comes out two orders of magnitude ahead of Ruby, Python, PHP etc. in the more algorithmic, less memory-allocation-intensive benchmarks above)
  • Ruby method calls are slow (although, because of duck typing, they are arguably faster than in strongly typed interpreted languages)
  • Ruby (with the exception of JRuby) does not support true multithreading
  • etc.

But, then again, slow with respect to what? Ruby 1.9 is about as fast as Python and PHP (within a 3x performance factor) when compared to C (which can be up to 300x faster), so the above (with the exception of threading considerations, should your application heavily depend on this aspect) are largely academic.

What are your options as a Ruby programmer if you want to deal with this "slowness"?

Write for scalability and throw more hardware at it (e.g. memory)

Which version of Ruby would best suit an application like Stack Overflow where speed is critical and traffic is intense?

Well, REE (combined with Passenger) would be a very good candidate.

Cheers, V.

vladr
Garbage collection itself is not necessarily slow, but the MRI's garbage collection is. If you need faster Ruby, you can also look at JRuby as well as REE.
Andreas
"Ruby 1.9 vs. C (gcc)" link is wrong
M28
Thanks for the link to the computer language shootout Vlad. REE does interest me too, and since I have RVM installed, I imagine I'll have a shot at it soon.
stephenmurdoch
Why are you linking to pages that say OUT-OF-DATE! The benchmarks game has measurements made with up-to-date versions of those languages, made a few weeks ago.
igouy
@igouy, True, mid-2008 may have been extreme. I updated the links, but they will in turn become out-of-date in a few months. :) Either way, the hardware and some patchlevels may have been different, and a few additional tests were added, but the bigger picture of things did not change.
vladr
>> out-of-date in a few months << No. As new versions become available new measurements are made.
igouy
>> within the same order of magnitude << It's within the same order of magnitude if you live to 7 or live to 69. Is that difference insignificant?
igouy
+2  A: 

Joel on Software - Ruby Performance Revisited quite well explains it. Might be outdated though...

I would recommend to just stick with it as you're used to Ruby on Rails,
if you ever meet a performance issue you might reconsider to use a different language and framework.

In that case I would really suggest C# with ASP.NET MVC 2, works very well for CRUD apps.

TomWij
Thanks for the link, I always like reading Joel's take on things. Interesting remark he makes about DHH's "bumper-sticker slogan"...
stephenmurdoch
+7  A: 

The answer is simple: people say ruby is slow because it is slow based on measured comparisons to other languages. Bear in mind, though, "slow" is relative. Often, ruby and other "slow" languages are plenty fast enough.

Bryan Oakley
yeah, that's what I was thinking, I mean, people say it's slow, but it's still darn quick for my requirements...
stephenmurdoch
>> it's still darn quick for my requirements << It's fast enough for everything that doesn't need to be fast :-)
igouy
A: 

First of all, do you care about what others say about the language you like? When it does the job it has to do, you're fine.

OO isn't the fastest way to execute code, but it does help in creating the code. Smart code is always faster than dumb code and useless loops. I'm an DBA and see a lot of these useless loops, drop them, use better code and queries and application is faster, much faster. Do you care about the last microsecond? You might have languages optimized for speed, others just do the job they have to do and can be maintained by many different programmers.

It's all just a choice.

Frank Heikens
A: 

People say that Ruby is slow because they compare Ruby programs to programs written in other languages. Maybe the programs you write don't need to be faster. Maybe for the programs you write Ruby isn't the bottleneck that's slowing things down.

Ruby 1.9.1 compared to Javascript V8

Ruby 1.9.1 compared to ordinary Lua

Ruby 1.9.1 compared to Python 3

igouy
+8  A: 

Why is Ruby considered slow?

Because if you run typical benchmarks between Ruby and other languages, Ruby loses.

I do not find Ruby to be slow but then again, I'm just using it to make simple CRUD apps and company blogs. What sort of projects would I need to be doing before I find Ruby becoming slow? Or is this slowness just something that affects all programming languages?

Ruby probably wouldn't serve you well in writing a real-time digital signal processing application, or any kind of real-time control system. Ruby (with today's VMs) would probably choke on a resource-constrained computer such as smartphones.

Remember that a lot of the processing on your web applications is actually done by software developed in C. e.g. Apache, Thin, Nginx, SQLite, MySQL, PostgreSQL, many parsing libraries, RMagick, TCP/IP, etc are C programs used by Ruby. Ruby provides the glue and the business logic.

What are your options as a Ruby programmer if you want to deal with this "slowness"?

Switch to a faster language. But that carries a cost. It is a cost that may be worth it. But for most web applications, language choice is not a relevant factor because there is just not enough traffic justify using a faster language that costs much more to develop for.

Which version of Ruby would best suit an application like Stack Overflow where speed is critical and traffic is intense?

Other folks have answered this - JRuby, IronRuby, REE will make the Ruby part of your application run faster on platforms that can afford the VMs. And since it is often not Ruby that causes slowness, but your computer system architecture and application architecture, you can do stuff like database replication, multiple application servers, loadbalancing with reverse proxies, HTTP caching, memcache, Ajax, client-side caching, etc. None of this stuff is Ruby.

Finally, I can't find much news on Ruby 2.0 - I take it we're a good few years away from that then?

Most folks are waiting for Ruby 1.9.1. I myself am waiting for Rails 3.1 on Ruby 1.9.1 on JRuby.

Finally, please remember that a lot of developers choose Ruby because it makes programming a more joyful experience compared to other languages, and because Ruby with Rails enables skilled web developers to develop applications very quickly.

Jay Godse
>> Most folks are waiting for Ruby 1.9.1 << ? "The current stable version is 1.9.1." http://www.ruby-lang.org/en/downloads/
igouy
@igouy - You're right. However, Ruby 1.9.1 isn't quite there with Rails, JRuby, etc. It'll come...
Jay Godse
Given that Ruby 1.9.1 was released a year ago, my guess is that you mean Rails isn't quite there with 1.9.1 and JRuby isn't quite there with 1.9.1? Rails hasn't caught up and JRuby hasn't caught up. (Your's was one of the more balanced, less fanboyish replies.)
igouy
In particular "Remember that a lot of the processing on your web applications is actually done by software developed in C" needs be chanted everytime "After all, few people write web applications in C" conveniently forgets 3 out of 4 LAMP technologies.
igouy
after much consideration, I have decided that this is the best answer. Thanks, I like the analogy about the signal processing app. It's easier to see what people are talking about now after all these helpful answers.
stephenmurdoch