Professional Ruby on Rails™

13.2. Fixing Performance Problems

Hopefully, I've established that, as a Rails developer, you have access to lots and lots of data about performance issues in your application. The question then becomes what to do with that information. When is it time to try and remedy a potential or an actual performance problem, and what sort of intervention is feasible? We all know that premature optimization is bad, but who gets to define when it's premature? The pressure from clients and managers to speed up code, even early in development, can be hard to resist, and people unfamiliar with Rails or Agile development styles may be unwilling to trust that speed improvements will come.

As a somewhat simplified guide for when to optimize, I find that performance enhancements tend to fall into one of the following three groups:

• Good practice techniques that happen to also have good performance characteristics. An example might include limiting the amount of data you create in a controller method. It's good practice because thin controllers are easy to test, and has a good performance profile because there's some overhead involved in passing the controller instance variables around. Similarly, splitting views into separate partials is both easier to read and easier to cache. These aren't enhancements as much as things that you should just be doing as part of your regular practice.

• Legitimately suboptimal implementations in your code that can be fixed by bringing the code in line with standard Ruby ...