Comments on: Top 10 Ruby on Rails performance tips

By: evan

evan — Wed, 30 Nov -0001 00:00:00 +0000

I have to take issue with most of these tips. Most of them are a lot of work for incremental benefit, many decrease maintainability, and some will affect your stability (e.g., patching the interpreter). Method dispatch is not really that slow. Is there some deployed app you are basing these suggestions on?

By: josh

josh — Wed, 30 Nov -0001 00:00:00 +0000

I agree with Evan. While you claim not to advocate premature optimization, that’s just what you are doing. “Sometimes you may want to trade off just a bit of elegance and abstraction for speed.” Then it’s just a matter of degree.

Much of your advice consists of saying “don’t use Rails feature X”. If you don’t want to use Rails, then don’t use Rails. I find it poor advice to try to turn Ruby on Rails into Java or PHP.

By: Tyler

Tyler — Wed, 30 Nov -0001 00:00:00 +0000

I think these suggestions are fine and agree with a good number of them. Antonio is simply telling readers about practices that can impact performance on high-volume websites. It doesn’t matter what framework you use – you’re almost assured of needing to sacrifice code elegance for speed if your performance requirements are in the upper percentiles. I’d understand the objection if Antonio had said that all Rails programmers should avoid these features right from the start… but he didn’t say that.

By: PJ Hyett

PJ Hyett — Wed, 30 Nov -0001 00:00:00 +0000

Then the question becomes at what point do you actually need to bother with any of these.

We receive ~12 million pageviews per month and go out of our way to write elegant and readable code at the expense of efficiency.

By: Mazdak

Mazdak — Wed, 30 Nov -0001 00:00:00 +0000

josh, you are clearly overreacting. He is by no means suggesting that you should stop using Rails. He is just pointing out some tips that might help make things better. But I do agree with the points made about most of these optimizations being “best practices” rather than real optimizations. If MUST measure before optimizing, but it’s good to keep things in the back of your mind as you code, e.g. not using too many ivars.

By: big o

big o — Wed, 30 Nov -0001 00:00:00 +0000

i think the negative reactions here are, at base, a product of the fact that if you are really in a position to be needing to do these optimizations, you should probably know all these things anyway. put another way: if you’re not aware of most of these issues, maybe you shouldn’t be in charge of optimizing a project that requires this much optimization.

Having said that, I do have some constructive comments:
– The author is dead right about the speed of REXML. REXML (in DOM-style mode, at least) is unforgivably slow if you’re parsing large files (ditto for massive quantities of small ones). If you can guarantee their well-formedness, Libxml is unbelievably fast. If you can’t, consider Hpricot’s XML mode. REXML’s stream parser might be decent, haven’t really used it.

- there’s been some research to indicate using MemCache for sessions when you don’t need it (if your session count is small) might actually be slower than SQLSessionStore.

- the ‘use your database’ comment suggests stored procs but neglects to mention: optimize your indexes. analyze your queries, figure out what keys you’re using for your selections, and add appropriate indexes. this will make a significant difference in a lot of cases.

finally: simplify. Four out of five times I find that inefficiencies in an app are the result of overly complicated design. It might very well be okay to use some crazy finder method like Foo.find_by_bar_and_mother_id_and_age_and_genetic_imperative(),
but it probably shouldn’t be in a loop that executes 1,000 times.

Three cheers for the zen of software development.
-o

By: Ryan Allen

Ryan Allen — Wed, 30 Nov -0001 00:00:00 +0000

Why oh why have we stopped talking about patterns!

By: Mark Carey

Mark Carey — Wed, 30 Nov -0001 00:00:00 +0000

Some of the suggestions are common sense (ie- don’t initialize variables you don’t need, besides it makes for ugly code), others are over the top (ie- patching the interpreter).

Your comment about using HTML neglects the fact that there are plugins that add rake tasks to pre-render your views to HTML to gain that optimization only in production mode. There are other plugins to optimize your assets as well (ie- asset_packager).

Using non-standard versions of an interpreter is very unwise. As the language changes and grows you are forced to maintain your patched version as the interpreter evolves or never upgrade.

One thing to keep in mind is that hardware is cheap and if you are driving the kind of traffic that would force you to sacrifice elegance for efficiency then you should look at adding more hardware to your deployment. Using finders and filters are part of what makes Rails so powerful, their cost in performance is justified by the cheapness of hardware and the time saved in development and maintainability of the code.

Leveraging the DB is one optimization suggestion I fully support. DB’s are capable of doing some serious heavy lifting with things like views and stored procedures. If you are writing an application that will always use a specific DB then it makes total sense to leverage the benefits of that DB. However for the sake of maintainable code, it would be wise to keep the custom SQL out of the controller and in your model, with healthy and clear documentation.

By: David

David — Wed, 30 Nov -0001 00:00:00 +0000

Very sensible advice Antoni.

By: dejan.dimic@gmail.com

dejan.dimic@gmail.com — Wed, 30 Nov -0001 00:00:00 +0000

I adore this kind of discussions.
It is always good to remind that the frameworks enable us to work fast but some time don’t produce optimize code. This compromise we made every programming day. Should we think about the speed while we build the application or should we first build than measure and then optimize. Like some philosopher said – it is all meter of equilibrium.

I don’t want to propagate my way of doing things but I feel the need to share some of mine experience in a general meaner. Developing real-time applications is mine domain for the last ten years. Every tick counts. On the other side the systems that we develop are too big with a lot of code, unnumbered classes and far to menu methods. Last time I check the source has approximately 0.5 Gb.
Usually I describe mine position as a flight control, kipping in mind the picture how the system operate and just know where to look.

While developing something you should always kip in mind that request are:
– it should work as supposed to,
– be able to find misbehaviors fast and precise,
– you or somebody else will change this code in a six months time under very big pressure and should be able to understand fast what the class, method or system should work,
– this peace of code could stay forever or could be replaced tomorrow with no implication on a rest of the system.

It is hard to make the right balance to all of these requirements, but finding the perfection is hard by its definition.

Some rules of tomb from experience:
– think twice before you code,
– design patterns are your best friend,
– comment code as much as you could,
– write unit tests for every system you build,
– benchmark you code to find the bottlenecks and deal with them first,
– premature optimization is the root of all evil.

Programming is an engineers discipline – we solve real problems in a real time for the real people and we enjoy doing it.

I am fully aver that I didn’t say anything new, but we oath to remind us from time to time about it.