PHP: Micro vs. Macro optimization, or "Get the low hanging fruit first"

After using and developing PHP for a few years now, i heard pretty much stuff about optimization, special technice's and other myths and fairy tales. But this article is not about tips or tricks, it is about if this the real key to better performance.

Nearly all of us have heard about hints like "static method calls are faster" or "++$i is faster than $i++". First is wrong, second is true by the way, but more important is the question, does it really perform better in overall?

I would like to categorize the optimization possibility's into micro-optimization and macro-optimization.

Micro-optimization:

I already mentioned the ++$i tip. This would be a perfect example for a micro-optimization. Imagine you have a website, just a normal one with a few thousand hits a day. Simple fetching articles from database and formatting/outputting these. Of course you could use ++$i instead of $i++, but what will be the achievement? Lets guess there are about 1000 PHP operations done on a normal page request. About 50 of them could be optimized with ++$i which is guessed 10% faster.

You saved 5 simple operations, what are about 0,5%.

This might look noticeable at first, but this is only the number of operations, not the real spend time where these 5 calls will not be measurable any more. Every request the PHP parser has to read and parse the PHP file. On every SQL SELECT there is the database overhead which also depends on database server load. Our previous result combined with that knowledge might be ~0.1% at the end. Conclusion: This kind of optimization simply does not make the page significantly faster.

Macro-optimization:

First, this is not about using macros like in C. No simple code substitution. It is the opposite of the micro-optimization. Once again a example with the simple imaginary PHP website. The main menu using JavaScript is generated by a complex SQL query on every request. This whole procedure takes about 10ms (unrealistic i know, but it is _just_ for the example calculation). 9ms for the SQL query and 1 ms PHP. For all of you who do not know why SQL is slower: Because there are sockets / TCP, database-daemon and harddisk access involved.

THIS is the point where we could use a macro-optimization.
Either, we could invest much work and create a different menu system without javascript and faster SQL queries, or we could do it a much easier.

If we have APC for caching (other anything else), we could use the following strategy:

After this optimization that _just_ affect the SQL fetching part, we have a APC cache request that might take ~1 ms. So we reduced our 9ms SQL to 1ms APC. Of course the overall benefit will not be that big, but will be notice- and measurable. But what really makes the point here is, that we need to query only 24 times a day and not on _every_ request.

Low hanging fruit

After reading about micro and macro optimization, you might understand the meaning of this much better.
There are several ways to optimize, some of them are easy and fast. These are the "low hanging fruit" - easy to pick. This fruits should be always the first thought when it comes to optimizing. Some of them can be found easily with profiling.
I want to give you a few hints for optimizing your PHP (Python, Ruby, ...) application.:

1. Keep an eye on the IO load. The harddisk of the server is mostly the slowest part and should be used only if necessary.

2. Try to avoid complex SQL querys. The database servers are often under heavy load, even if they have some integrated caching, there is still the SQL overhead.

3. Try to store results. If you need to analyse the browser of your clients, do not do this every request, save the needed values in their $_SESSION and check only if the UserAgent has been changed with a simple crc32 hash.

4. Try to cache. If you have parts in your code that are called nearly every request, have the same result and do not change often. Cache them! Some options are: APC, XCache, Memcache, eAccelerator, tmpFS.

5. Try to avoid unnecessary function calls. Try to store the result of that function and use it multiple times.

High hanging fruit

I do not say you should not use ++$i or static methods. I want to clarify that there are more important parts worth optimizing.
If you write new code, it should always be your aim writing the fastest code possible. Some of these tips floating on the internet might be helpful, but please check if they are true first!
Some tips i tested myself:
1. ++$i is faster than $i++
2. Static methods are not always faster. (source)
3. Relative paths are slower to include than absolute.
4. foreach is fastest for iterating over arrays. (benchmark)
5. floor and ceil can be replaced bei (int) casts. (benchmark)
6. Try to avoid preg_* function if possible. (benchmark)

Conclusion

If you are hungry, profile the tree first, then pick some of the large low hanging fruits.
While coding pick some of the tiny high hanging.
I hope you had fun reading about my point of view.

No related posts.

Geschrieben am Dienstag, 16. Februar 2010 und abgelegt unter MySQL, PHP. Verfolgen Sie die Diskussion zu diesem Beitrag per RSS 2.0 Feed. Die Kommentarfunktion wurde deaktiviert. Auch das "Anpingen" des Beitrages ist nicht möglich.