ingo() -> tech. % Ingo Schramm - PHP

PHP array_shift() does not scale

nospam@example.com (Ingo) — Fri, 27 Mar 2009 11:39:24 +0100

Arrays are at the core of PHP and act as the swiss army knife for data structures. They are known as an efficient and generic solution. But this is only half of the truth. The internal C representation as a hash table causes a non-intuitive performance behaviour of arrays. Associative arrays for example scale badly in key size and the different accessing functions like array_pop() and array_shift() behave very differently in respect to performance. I made a quick benchmark to visualize the difference. At least in loops it is more efficient to reverse the array and pop it instead of simply shifting it. This is because an array_shift() - strange enough - forces a reindexing operation for each shift.

This blog post is an appendix to another blog post I wrote about benchmarking SPL data structures.

PHP Myth: static function call faster than instance function call

nospam@example.com (Ingo) — Tue, 18 Nov 2008 08:21:31 +0100

There exist a reasonable number of myths about PHP. One I will challenge today. If you ask an average PHP programmer whether a static function call or a function call on an instance performs better he or she will problably say - without thinking - static. This is wrong.

Sure, if you want to call a method on an instance you first have to instantiate that instance. This takes some time by its own. The sum of CPU time for instantiation and a single method call is in fact greater than the CPU time needed to call a static function. So, if you ask for the time of single calls you will support the myth. But the question is wrong.

In real life you will never do isolated calls. The question of interest is not how a single call performs but how the different kinds of method calls scale. If you measure this you will get a different picture. The instance calls scale definitely better. If you even have just a handful of static method calls on a class the same calls on an instance - a singleton for example - will save you time.

The image below shows a measurement with empty methods and light weight classes on PHP 5.2.5. The point where the two lines are crossing may vary with the complexity of your class.

How to improve PHP performance in 30 minutes

nospam@example.com (Ingo) — Mon, 17 Nov 2008 21:35:19 +0100

You've written a not so trivial PHP application and your web site is visited more and more frequently, 1 time per second, 10 times, 20 times per second, more. You transfered your database to a second mashine but still your webserver performance breaks down at 25 request per second. You install a byte code cache like the APC or XCache but your servers still do not deliver more than 30 or 40 requests. What now?

You may spend some weeks to refactor your whole software. Or you invest 30 minutes to fix your file inclusions and you win some 100% performance - even more.

The recipe is easy - watch your server process with strace, take care on file stats and try to reduce it to zero:

- reduce your include_path to a single entry or don't use it at all
- include or require absolute paths
- ensure that each try to include a file is a hit
- avoid file_exists(), is_file(), is_dir(), is_link() etc.
- avoid autoloading

That's it.

Each file system access forces the operating system to switch context and wastes a huge number of CPU cycles. If you have a long include path and the file to include is found at the end you have a lot of useless file stats. Even the byte code cache cannot protect you from this since it stores only files found, not files that do not exist. For each non existing file all the stats and lookups take place again and again. This is what your CPU works for, not your business logic.

Stats are evil.