Veröffentlicht am 12. März 2009 (vor 1528 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.
Kommentare bitte per E-Mail.
Diplom-Informatiker Stefan Priebsch ist IT-Consultant, Trainer und Spezialist für die Entwicklung PHP-basierter Software.
Er ist Autor zahlreicher Bücher und Fachartikel über verschiedene Aspekte des Software-Lebenszyklus und spricht regelmäßig auf internationalen IT-Konferenzen.
Stefan Priebsch ist verheiratet und Vater von Zwillingen. Er lebt und arbeitet in Wolfratshausen bei München und ist Mitgründer und Principal Consultant von thePHP.cc.
"I have had the pleasure of knowing Stefan for a few years as a fellow technology-presenter/educator. It is easy to whole-heatedly recommend Stefan, especially after having learned a great deal from attending a number of his conference presentations and sharing in-depth discussions on technology management topics."
--Eric David Benari, CEO, IT Management Group
Es wurde schon viel darüber spekuliert, wie groß der Anteil der PHP-Nutzer ist,
die von HipHop profitieren werden. Die Zahlen bewegen sich im Wesentlichen
zwischen 0% und 100%, daher versuche ich mich gar nicht erst an einer eigenen
Schätzung, sondern will stattdessen über die Voraussetzungen schreiben, die
ein Team beziehungsweise eine Firma erfüllen muss, um von HipHop profitieren zu
(vor 1192 Tagen)
» Blog-Eintrag lesen
A lot has already be speculated about what percentage of existing PHP users would benefit from using HipHop.
The numbers seem to range somewhere between 0% and 100%.
I will not try a guess myself, but rather try to shed some light on some the most important prerequisites I think there are for a company to benefit from HipHop.
(vor 1200 Tagen)
» Blog-Eintrag lesen
Der erste deutsche PHP Summit - powered by thePHP.cc - ist eine neue und
einzigartige Veranstaltung, die alle wichtigen Themen rund um die
Software-Entwicklung mit PHP in kompakter Form vermittelt.
(vor 1202 Tagen)
» Blog-Eintrag lesen
CRAP Presentation PHP 5.3 Blog Conference fail Montreal Training Slides Relaunch PHP Quebec 09 Migration Selenium Chicago Lifecycle CodeWorks09 Arne Blankerts Workshop Book thePHP.cc MVC Canada Sebastian Bergmann Magento HipHop Feedback Derick Rethans Testing OOP Atlanta MTA Webcast tek09 U.S.A. C++ Slideshare Facebook hack Wordpress PHP
RT @thePHPcc: 18 PHP Power Workshops in 3 Tagen? Klar geht das! Beim PHP Summit 2010 - http://phpsummit.de - Schnell buchen, bevor es zu ... (vor 1203 Tagen)
» Tweet lesen
New blog post: http://priebsch.de/blog/how-to-turn-bad-code-into-good-code/ (vor 1203 Tagen)
» Tweet lesen