Comments on: Top 10 Ruby on Rails performance tips

By: Ricardo

Ricardo — Mon, 30 Nov -0001 00:00:00 +0000

Rich what you said is hardly true. What do you do after your measured? This post helps answering that question.

By: Patrick

Patrick — Mon, 30 Nov -0001 00:00:00 +0000

Item #10 should be #1, as it is by far the most important tip. The worst case is premature optimization, concentrate on simple elegant code first. Once you see you need more speed, profile and benchmark your app to find the bottlenecks, only then should you start optimizing.

By: Josh

Josh — Mon, 30 Nov -0001 00:00:00 +0000

I disagree with Josh & Evan. The writer’s 10th point specify the intended usage for the other points. Good suggestions and some overreactions in an interesting thread!

Note: I’m a different Josh

By: pireland

pireland — Mon, 30 Nov -0001 00:00:00 +0000

I think Patrick brings up a good point. If you are writing a guide for “performance aware” style of coding, your first point should be about keeping your code simple and elegant.

Optimizing code isn’t the same thing as creating simple and elegant designs from the start.

Thanks Antonio for the tips! While I do not 100% agree with them all, I appreciate the different perspective and experiences. We should all realize that this is not meant to be a definitive guide, it is just one perspective. How about starting with saying with what you agree with and not start out by attacking. Keep it positive!

If you think you really do know more or can make a better guide, please write one and then post a link.

By: Bradley

Bradley — Mon, 30 Nov -0001 00:00:00 +0000

@Mark Carey: “Hardware is cheap”

While this is somewhat a true statement I feel that it misses a vital point – “money is money”. You mention that the development and maintenance (through nice and elegant code) time saved will justify the amount of money you will spend on new hardware. Yet, money is money and at the end of the day it makes sense (to the economists in all of use) to maximize the amount of money you put in your pocket (or minimize the amount you lose).

Thus, if I can save $10k on hardware by following a couple of Antonio’s suggestions it would be a wise move as long as the associated development and maintenance costs (in coding time) of the code change are less then $10k.

My main point is that sometimes it is a good idea to keep the code elegant even if it means throwing more hardware at your project, while other times uglier optimized code can be good! As I always say, “It’s all about balance” and each specific project has its own unique balancing act!

@Others

Finally, I think it is important to take all of Antonio’s tips as tips and NOT rules.

@Antonio

Thanks for the tips Antonio!

By: Rather not say

Rather not say — Mon, 30 Nov -0001 00:00:00 +0000

I agree with Bradley regarding hardware, also i’d like to add: who’s gonna mantain the extra hardware you throw at your app?

I’m a one man show (on my Django projects at night!) and when i build an app i have to do everything A-Z, i’d rather not maintain an extra server or have to hire somebody to maintain a proper “server farm” if i can avoid it by optimizing code. Rails and similar technologies allow us to compete against bigger teams of .NET/Java programmers.

I have a fulltime job during the day and here where i work we use SQLServer basically as we would be using MySQL with MyISAM tables: no FK constraints (they slow things up!!), only stored procedures are allowed, nolock hints _everywhere_ which gives the risk of reading uncommitted transactions.

And i’m talking of one of the top 50 most visited Internet sites and we certainly don’t lack money or personnell or talented people.

As i said, sometimes more machines are more headaches.

By: Rich Collins

Rich Collins — Mon, 30 Nov -0001 00:00:00 +0000

You can throw out this entire post and replace it by 3 things:

1. Measure
2. Measure
3. Measure

By: Anders

Anders — Mon, 30 Nov -0001 00:00:00 +0000

Well, what must also be mentioned is that when it comes to enterprise-size applications where optimizations of these sort are needed to handle the traffic, scalability is order of magnitudes more important than performance. So probably it is more worth the effort to make sure your application will benefit from an extra webserver, an extra database server, more memory or so on.
Often a overly optimized application is harder to scale linearly.

By: Ruby on Rails Examples

Ruby on Rails Examples — Mon, 30 Nov -0001 00:00:00 +0000

I would add:
Try to avoid URL_FOR to avoid url look up.

By: Roger Pack

Roger Pack — Mon, 30 Nov -0001 00:00:00 +0000

You may also want to look at the information in

http://www.infoq.com/articles/Rails-Performance
To help understand how to tweak rails performance 🙂 It seems very good on reporting some real world situations on it.

-Roger