New Relic delivers RPM Lite, a free version of its Ruby on Rails performance management tool. The free tool enables developers to tune performance of Rails applications even from their iPhones.

New Relic, maker of application performance management software for Ruby on Rails environments, has announced a new free version of its performance monitoring solution, as well as new features to its enterprise version.
(more…)

The performance of ROR is influenced by many factors, particularly the configuration of your deployment server(s). However the application code can make a big difference and determine whether your site is slow or highly responsive. Achieving good performance is a tricky business.
(more…)

There is interesting set of benchmarks covering many of PHP’s magic methods. Results correspond pretty well to my own benchmarks in the area. The thing to take away is that its not necessarily the overhead of the magic methods, but rather what you do inside them. Its hard to do anything useful inside a magic method, such as __get or __call that isn’t 10 to 20 times slower than the “non-magic” solution.

There are probably more than a few naive programmers who would read results like this and start to avoid these constructs in their own code for performance reasons. These are the same kinds of people obsessing over a few single or double quotes, who eschew “slow” objects in favor of switch statements that are many times slower than the polymorphic method calls they are trying to avoid.

But, that’s not the end of the story. These benchmarks were using 2,000,000 iterations. The N really matters here. Sure, iterators are slower than arrays, but you aren’t going to be iterating over two million things. I tend to fetch my database records in lots of 25 or 50. You aren’t going to be making two million invocations of __call. But how many will you make? Under what value of N does the performance of these techniques cease to matter? Is it ten, one hundred, one thousand, or ten thousand? You may be surprised at how few calls your program actually does and how little impact it has on performance.

Profiling is the way to find out the potential impact and to discover your true N.

call_user_func_array appears to be a bottleneck, but it turns out that its the function being called, htmlspecialchars, not the calling process that consumes the balance of the time. In that case, the function was “only” called 300 times. I find that order of magnitude to be fairly typical. Something to be aware of, perhaps, but not something to obsess over.