PHP micro-optimization tips
Why "micro-"? Because changing logic of your application may give you much better performance boost then applying all these tips. But they still can make your code better. You always need to output something, why do not use "echo" instead of "print"?
- calling an object method is faster then traping it with with "__call"
- calling a "static" method is faster then an object method
- calling a function is faster then calling a static method
- accessing a local variable is faster then then a global variable
- accessing a global variable is faster then an object property
- accessing an object property is faster then trapping it with "__get" and "__set"
- accessing an initialized variable is faster then accessing an uninitialized variable
- absolute paths in "include" and "require" are faster then relative
- merging several scripts in one file and then including it is faster then several includes
- "switch" is faster then "if ... else if ..." in some cases
- do not use regexs for simple string processing tasks
- avoid @ (error control operator)
- avoid notices and warnings in your scripts
- avoid unused variables and unused method parameters
- adding method parameter increases calling time
- adding method parameter type hint increases calling time
- unset variables that contain large amount of data or circular references
- $_SERVER['REQUEST_TIME'] contains script startup time
- cache page output or result of resource-consuming functions
- "echo" is faster than "print"
- "echo" accepts several arguments, you can use it instead of string concatenation
- "ob_start()" and "ob_end_clean()" is may be better then several string concatenations
- strings in single quotes ('...') are processed faster then strings in double quotes ("...")
- pre-increment (++$i) is faster then post-increment ($i++)
- "isset" is a faster alternative to "array_key_exists"
- an array is a faster alternative to a class with several fields
- "foreach" is better then "for" in many cases
- open resources (files, database connections, sockets) right before using them, free resources as soon as you do not need them
- do not fetch database fields which you do not use in your script
- use prepared database statements
- combine several queries in one when database supports it
Some valuable comments:
- hankjmatt: Switch statements may be more efficient in other languages, and sure they are more readable than an endless chain of else ifs, but in PHP I believe switches and else ifs behave the same hence the work by Stefan Esser at http://www.suspekt.org/switchtable/ to optimize the jump tables.
- "if ... elseif ..." may be faster when variables are checked with strict equality comparison (===).
- Be careful replacing array_key_exists() with isset(). The isset() function returns false if a value is set to null.
2011-05-21 12:30 - I've decided to actually test several of them using different physical machines and different versions of PHP. You can find my initial findings documented on http://micro-optimization.com.
2011-11-19 15:57 - Mihai Stancu - Could you give an example of a size of project where such differences would make a big impact on performance?
I agree with most of your suggestions and have either tested or heard of them before.
But on the projects i worked on the sum of the speed-ups you could obtain from all of these suggestions is at least one order of magnitude smaller that just one slow query or a few hundred file reads.
They are all good practice advices and i still take good care in using them.
2011-11-20 04:05 - Alex - A few years ago I worked on a project with a very specific requirements: no access to the file system, no database access, no opcode caches and performance should be very good. As result, we created a translator that converts OOP code with type hints and other features to procedural code, which gave us significant performance improvement.
But using these tips in typical PHP project only can give you a feeling that your code is a little bit close to perfect one. If the performance is critical, other techniques should be used - caching, etc.