Benchmarking PHP’s Magic Methods
November 4th, 2007Larry Garfield has an interesting set of benchmarks covering many of PHP’s magic methods. His 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. Larry ran his benchmarks 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.
As Wez and Travis point out in their comments, profiling is the way to find out the potential impact and to discover your true N.
Paul M. Jones has a good example of what I’m talking about. There, 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.
All Posts
November 4th, 2007 at 11:30 pm
Thanks for this post.
It’s really stupid when people want to speed up their php code this way.
November 5th, 2007 at 8:02 am
Hi Jeff — I agree with your points, and want to add a little clarification about my blog post.
Although using call_user_func_array() is technically about half as fast as a direct function call, you have to remember (1) it’s only one call in a , and you’re not using it very often at that, and (2) in general terms it’s still *very* fast, especially in comparison to all the other things you have to do (e.g. as you point out, hitting the database).
In short, if your application bottlenecks really are call_user_func_array() or related, and **nothing else**, then you’re doing pretty darn good.
November 5th, 2007 at 8:10 am
I how you use these really depends on what you are doing. Larry is looking at drupal specific uses. And, when something gets implemented in drupal performance is always a big concern. With the number of high volume sites running drupal this makes sense.
If I have a low volume site performance might not make as much of a difference. If I have a high volume site I’m going to fight for every cpu cycle.
November 12th, 2007 at 2:47 am
I totally agree. You can’t really predict where the main bottleneck is going to be, although you can have an educated guess - for instance, polling a database within a loop is most certainly going to be a kludge and you might want to rethink your approach.
However, optimizing too early can easily leave you with unnecessary “speed hacks” in your code, making it harder to understand and maintain. Perhaps the “right” approach might be pondering about and selecting the optimal algorithm for the task at hand, then implementing it in the most elegant, readable and maintainable way - and then, as you watch your app perform, you can pinpoint the exact places where the execution time stalls most and fix that.
December 19th, 2007 at 12:02 pm
WOW! I never knew this was true. Thanks!
December 26th, 2007 at 8:07 pm
Interesting,
What’s more is that in most cases the performance gain from any such optimization is sometimes negligible when compared with the latency of rendering back to a browser across the web. Consider the context of application…
- Shelon Padmore
March 28th, 2008 at 4:58 am
i wonder if cost of these methods on speed of php is too much why php’s development team devoleped these methods??? . i think if there is such problem they will fix it next versions of php.
July 3rd, 2008 at 5:46 am
It is just useful to keep these functions in mind. Programms becoming flexible this way.
P.S. Many thanks for the post.