Before continuing, a disclaimer: do not take these tips and refactor your code ad-hoc. Take everything with a grain of salt and perform your own measurements to determine which pieces of your app are slow. Before making any performance optimizations, get set up with a profiling tool, like RubyProf, New Relic, Scout, etc. You always want to know where the most significant bottlenecks are for you, and focus your efforts there first.

Eager Load Associations

The most common and significant problem that I've seen in Rails apps has been the lack of eager loaded associations. A simple extra _:include_ when performing ActiveRecord finds will prevent 1+N queries. So for example, if you are displaying a list of articles on your blog homepage and want to display the author's name as well, load the posts with Post.all(:include => :author). For those complex pages, eager loading works multiple levels deep. Newer versions of ActiveRecord handle complex eager loading cases much more elegantly by splitting up a large join query into multiple smaller queries that make better sense.

Note: only perform the eager load when you actually plan to use the objects, because there's fairly significant overhead to creating many ActiveRecord objects.

Do Database Work In the Database

In the same vein as the first tip, try leveraging the database when it makes sense. Relational databases are designed to query large amounts of data and return results; Ruby is not.

For example, if you want to check if the user currently logged in has commented on an article, you don't need to load all the comments for that article. Iterate through each one, and check whether at least one comment was created by the current user. Doing this will instantiate objects for every single comment and then instantly discard them after the check is done. A much better way to obtain the same result is to push the logic to the database by doing a SELECT COUNT statement. ActiveRecord has an easy way to do this: Article.comments.count(:conditions => ["user_id = ?", current_user.id]) > 0

Do as Little as Possible During the HTTP Request Cycle

You want to be able to return a response to the end user's request as quickly as possible, so only do the bare minimum needed to return the response and defer everything else. Actually sending out an email is relatively slow and users don't generally care if emails are sent during the request cycle or right after.

Whether this is implemented using a simple Ruby thread or a robust, distributed queuing system like RabbitMQ doesn't really matter. Rails 3 will ship with a default queuing system, but until then, I suggest checking out DelayedJob and BackgroundJob.

Know Your Gems and Plugins

As Rails applications get more complicated, a good thing to do is to use existing plugins and gems instead of recreating the work in house. This usually introduces a significant amount of new code to the application that is relatively unknown.

There are many great Rails plugins out there. But before depending on a new gem or plugin, I suggest at least skimming the source -- check for any craziness. Also be sure you're using plugins for their intended purposes -- or things are likely to go awry.

Avoid Creating Unnecessary Objects

Every time Ruby's garbage collector is triggered, Ruby will stop running your code and start cleaning up unused objects. This process can take between 100 and 400ms on MRI (JRuby has a better behaved, tunable garbage collector through the JVM), which is a noticeable period of time. Avoid this as much as possible. This means avoid creating unnecessary objects. I have already mentioned a couple of ways to do this in the previous tips.

In general, the best way to avoid the unnecessary creation of objects is to understand how Ruby and the libraries in use work. For example, understand the difference between these two snippets:

sentences.map { |s| s.strip }
sentences.each { |s| s.strip! }

The first snippet creates a new Array object and a new String object for each element in the Array. The second snippet just mutates the String objects in the Array without creating new Ruby objects.

Granted, this tip only makes a significant difference when dealing with large data structures, but it's a good idea to keep in the back of your mind whether or not you actually need to duplicate objects. If you have arrays containing thousands of ActiveRecord objects and use reject vs. reject!, you've just created a second array which could potentially have thousands of objects.

There are many other aspects of a Ruby on Rails application that can cause bottlenecks; listing them all is obviously impossible. That said, the most important thing to learn is how to locate these bottlenecks. Solving them can be handled on a case by case basis.

I first heard about everything this past Thursday. There had been some communication between DHH and Yehuda. The short version is that DHH had nothing but praise for Merb and insisted that he would actually like Ruby on Rails to take a similar direction as Merb, and there was talk of Merb and Rails working together. Now, to say that I took this idea poorly would be an understatement. I've had an idea of Rails painted in my head for the longest time. In my mind, it was a software package that enjoyed locking you into it's way of doing things, laughed at the concept of modularity, and probably killed a few babies along the way... for good measure. How could we all work together?

Well, I thought that it would be best to hear them out, if only to know what they were planning. So, we all spent a bunch of time talking. DHH and the rails core team only had good things to mention about Merb and its philosophies. Not just general philosophies were discussed either, but specificities about implementation. The more we talked, the more it started to dawn on me that they were actually serious about making this happen. A list of a few of the points have been mentioned in the announcement. Let's be honest, that basically is Merb.

Anyway, I'm sure you all don't want to hear all the gory details of how I went all :emo:. It did feel for a bit like I was losing my baby. In the end though, I did reach acceptance. The truth is, Merb has won. We have proven to the ruby community that not only do our ideas work, but they are the better way to approach things. Rails is going to be adopting the Merb philosophy no matter what. I was faced with the decision of either helping them get there or fight a completely pointless battle.

So, in the end, I am proud to say that I made the choice that benefited the entire ruby community. I really believe that, together, and with a lot of hard work, we can end up with a solution that will stand true to Merb's core tenets while at the same time keep the appeal that originally drew so many of us to ruby web development. Really, this proposition has me quite excited.

Pretty much all of the reasons I could think of to not try this ended up being moot. Such as, competition between frameworks is a good thing. Yes, it is, but we already made the bulk of our points with Merb... successfully. Hence the plan to make all of those points part of Rails 3.0. Another reason might be that personalities could clash. Granted, there is no way to know for sure until the project is actually successful, but I have not really picked up on anything that would indicate this while talking with the rails team. Really, there are a million reasons why this couldn't work. I think that if both sides are in this 100%, we can only succeed.

I know that there are still many issues to address, such as migrating existing Merb applications from 1.x to 2.0 (aka Rails 3.0). Don't worry, I'm in the same boat. I still have a myriad of Merb 1.0 applications to deal with, but there will be plenty of effort put into smoothing it all out. For one, once rails-core (or whatever it will be named) is done, merb-more will be ported to run on top of it. Intermediate releases of Merb which will start converging towards the common point as well as provide plenty of deprecation notices of things that change. More details of this will become available shortly on my blog, on the mailing list, and on IRC.

So, that's that. This really is huge news and will most likely feel like a blow to merbists everywhere, but really, it shouldn't. The people who made merb great are still going to be doing that. The community that made merb great is still going to be there. This should feel like our coming home. We're going to be making Rails everything we dreamed of and more. We're going to take over the world!