Archive for April, 2008

Rails url_for is slow — some data comparison

There has been some discussion, though not a lot in print, of the fact that the Rails helper method url_for (which is also the basis for link_to and other frequently-used helpers) can be slow. This slowness stems from the process of generating routes, which takes longer as your routes.rb fills up.

As the Zvents site and traffic grow, we’re always looking for opportunities to improve performance. Our routes.rb has filled up a bit (nearly 40 entries), so I decided to do a little benchmarking to see if url_for was slowing us down, and if so, how much.

Here’s what I found.

I started with a page that has approximately 200 links generated with link_to (http://www.zvents.com/movies/theaters, though the number of links depends on your location). This is a lot of links, but that made it easier to run my tests. I wrapped each link_to call with a timing block, summed up the time, then took the average. Also, these tests were run on my development machine (MacBook Pro) in a Linux VM, under fairly heavy load.

Here’s the difference between calling link_to with a hash (causing a call to url_for), and calling it with a string (no call to url_for), average over roughly 1,000 measurements:

link_to WITH url_for: 6.8 ms

link_to WITHOUT url_for: 2.0 ms

That’s a big difference — almost 5 ms, or 3.4 times longer. And the cumulative effect on a page like the one tested, with nearly 200 links, is a total render time of almost one second more.

Obviously, the results will be very different on different machines, in different environments. I’d love to do a more general, scientific analysis, when I have some time. But for now, it’s just a little more information for you to use in trying to streamline your Rails apps.


General Performance and Scalability Rails Ruby
, , ,

If you enjoyed this post, make sure you subscribe to my RSS feed!

Comments