Larry 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.
Feed
Subscribe to this blog…
Thanks for this post.
It’s really stupid when people want to speed up their php code this way.
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.
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.
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.
[...] on LAMP and Web 2.0 .NET: SocialText, Blogging Developer, Don Dodge, Geeks With Blogs, SQLBlog.com, PHP blog — John Pavley Sphere [...]
WOW! I never knew this was true. Thanks!
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
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.
It is just useful to keep these functions in mind. Programms becoming flexible this way.
P.S. Many thanks for the post.
At the end of the day, while i develop coderprofile.com i simply write code that looks the nicest and scales well and not do stupid things like loop over 1000 records from the database! You can always cache and speed up script execution in many other ways instead of waisting your time with ” ” vs ‘ ‘ and microseconds!
Chances are that front end speed such as delivering css files, js files, images etc are really what the user is waiting for… not the generation time of the page. Take a look at YSlow for FireFox and you will see what i mean.
Kind regards,
Scott
Great article – I agree 100%. I kind of touched on the same subject on my blog with a recent article I wrote, though admittedly in probably too harsh of a way:
http://www.vancelucas.com/article/early-performance-benchmarking-is-a-disease/
Your points are exactly what I was getting at though – obsessing over performance when it isn’t even a problem kills your development.
Really Gr8 ! I have used some of them but i was not knowing regarding speed and performance . thanks for sharing this…
If your article marketing campaign consists in merely submitting an article or two every week, your results will be likely very poor, It takes more than a few articles submissions a week to get results. In fact, those who are successful are definitely submitting at least 5 to 10 articles each day. While they may find this very time consuming, they find the results keep them motivated to keep on, that’s why you must invest some money in softwares. Article spinner and submitter tools are the best ones you must acquire that will massively help you leverage your article marketing campaigns.
What a great blog. Glad to see that it is so popular.
What a great blog. Glad to see that it is so popular. I was looking for a good place to read in my free time.
go on, this blog is very Valuable
Awesome this is a great share, thank you for putting this article together! Saw this post tweeted by odegard media on twitter. Looking forward to more and will reply to those who comment back for next months group meetup!
You made some good points there. I did a research on the topic and found most people will agree with your Post.
I don’t know what to say except that I have enjoyed reading