Why do people say that Ruby is slow? [closed]

Answer 1

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.

Answer 2

Performance is almost always about good design and optimized database interactions. Ruby does what most web sites need quite fast, especially more recent versions; and the speed of development and ease of maintenance provides a large payoff in costs and in keeping customers happy. I find JAVA to have slow execution performance for some tasks, and given the difficulty of developing in JAVA, many developers create slow applications regardless of the theoretical speed capability as demonstrated in benchmarks (benchmarks are generally contrived to show a specific and narrow capability). When I need intensive processing that isn't well suited to my database's capabilities, I choose C or Objective-C or some other truly high performance compiled language for those tasks depending on the platform. If I need to create a databased web application, I use RoR or sometimes C# ASP.NET depending on other requirements; because all platforms have strengths and weaknesses. Execution speed of the things your application does is important, but after all, if execution performance of one narrow aspect of a language is all that counts; then I might still be using Assembler language for everything.

Answer 3

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 2.1 compared to Javascript V8

Ruby 2.1 compared to ordinary Lua

Ruby 2.1 compared to Python 3

Answer 4

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.

Answer 5

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.

Answer 6

The way to deal with Ruby's performance in Web application is the same as with any other programming language:

ARCHITECTURE

This is easier to do in Rails than in most other Web Frameworks.

At the application level, by caching whatever is supposed to be cached and by managing the access to the DB in an intelligent way (since the bottleneck is usually on the "DB" access for most WEB apps).

Rails makes it very easy and natural to solve these problems. There are several abstractions for caching data, pages and fragments, and there are also very nice abstractions to deal with the SQL part in an optimised and reusable fashion (Active Record and AREL).

This is the reason why so many applications written in faster and not-so-expressive languages (like php) end up being slower than the Ruby counterparts. It's not so easy and elegant to tackle caching and querying with these languages than it is with Ruby.

At the infrastructure level it is reasonable to think of load balancing and all that stuff that I do not happen to know a lot about. I'd outsource that problem by hiring some platform as service provider, like Heroku or Engine Yard. Anyway. Deploying rails with load balancing is probably not very hard to do.