The Five Immutable Rules of Optimization

Veröffentlicht am 12. März 2009 (vor 504 Tagen)

Alex Netkachov recently posted the article PHP micro-optimization tips on his blog. This article has already stirred up some reactions. I want to put some more oil in the fire: while there is nothing wrong with using some of Alex optimization tips, I consider a quite a few of them harmful, namely those that suggest not to use OOP. Let me elaborate.

First of all, since PHP is an interpreted language, by definition, it will always be slower than a compiled language (let aside the fact that opcode caches like APC exist to work around this problem), not only because the program is re-compiled every time it is being executed, but also because compiling "offline" allows for complex optimizations on the binary code. Good compilers do that, for PHP code it does not make sense to do this extensively at request time, because you can never tell if the time it takes to optimize the code will be overcompensated by the runtime gain.

If you know that you desperately need performance, then consider writing C code, or even Assembler code. But the better performance will come at the cost of the code being less readable. There is no doubt Assembler code is very hard to understand (unless you are a microprocessor). C code, especially when making extensive use of pointers, pointers to pointers and such, is, at least to me, also much less readable than PHP code.

As (PHP) programmers, one of our primary goals should be to create maintainable code. That means that code should be easy to read (for humans), and easy to extend in the sense that you do not have to touch existing code to add new features, or modify existing ones. OOP techniques, if applied correctly, give you exactly that.

When programers justify not (properly) using OOP (or not using OOP at all) with "OOP is slow", I usually tell them that I think they have chosen the wrong language in the first place. When execution speed is your primary concern, PHP might just not be the right choice for you. Still, PHP is definitely "fast enough" for you, even if you make rather extensive use of OOP.

My suggestion is to write good, readable, and extensible OOP code. Do not optimize the code as you write it (remember Donald Knuth's famous quote "Premature optimization is the root of all evil").

If you find that you have to optimize code, please make sure you follow the following five immutable rules of optimization.

Rule #1: Know what to optimize for

The first rule of optimization is to understand what you are optimizing for. A program can be optimized either for more speed or for less memory usage. Both are competing goals. A program optimized for low memory consumption will usually run a lot slower than a program optimized for speed, which in turn will use more memory.

It is also important to note that optimizing code for speed is not always the right thing to do. It may be in most cases, but when you want to allow processing of more concurrent requests by the server, code may have to be optimized for lower memory consumption.

Below, we will focus on performance optimizations.

Rule #2: Use a bytecode cache

The second rule of “optimizing” PHP code for performance is: use a bytecode cache. This gives you an instant performance boost that is usually much bigger than any code optimizations.

Rule #3: Cut down I/O

The third rule of optimization is: cut down I/O, because I/O is where the action is. Every file system access, database access, or access to a remote system is very, very slow compared to executing PHP code. Actually, it is estimated that you can execute about 2000 lines of PHP code (that causes no I/O operations) in the time it takes to complete one disk request.

This relation should make it very clear that there is absolutely no point in making a lot of micro-optimizations when you can instead save just one I/O request. If you cannot avoid I/O, use as much caching as possible, so that even though _some_ requests take rather long to process because they need to access the database, subsequent ones will execute a lot faster because the data can be loaded from the cache.

Rule #4: Use Caching

Thus, the fourth rule of optimization is: for every I/O request you cannot avoid, use caching whenever possible.

Rule #5: Profile the Code

The fifth rule is: always profile your application before you start optimizing. Make sure your optimization efforts are based on facts and figures, not on a wild guess where the application spends most time. Obviously, optimizing code that is executed many times will give you a better overall result than optimizing a statement that is just executed a few times.

This, again, also implies that you should not start to optimize as you write the code. Complete your application first, then see if it is fast enough. Do not even consider optimizing your code before you actually encounter performance problems while testing or in production.

Tags: PHP, Optimization, APC, Profiling, Performance, Best Practices

««« Vorheriger Eintrag

Nächster Eintrag »»»

Kommentare?

Kommentare bitte per E-Mail.