zorg.ch
by @ 17.10.2007 13:28, edited @ 17.10.2007 13:29 - nach oben -
Zorg optimieren

Ungekürzter Text aus Reinhold Weber's Blogpost "40 tips for optimizing you PHP code"

If a method can be static, declare it static. Speed improvement is by a factor of 4.
echo is faster than print.
Use echo's multiple parameters instead of string concatenation.
Set the maxvalue for your for-loops before and not in the loop.
Unset your variables to free memory, especially large arrays.
Avoid magic like __get, __set, __autoload
require_once() is expensive
Use full paths in includes and requires, less time spent on resolving the OS paths.
If you need to find out the time when the script started executing, $_SERVER[’REQUEST_TIME’] is preferred to time()
See if you can use strncasecmp, strpbrk and stripos instead of regex
str_replace is faster than preg_replace, but strtr is faster than str_replace by a factor of 4
If the function, such as string replacement function, accepts both arrays and single characters as arguments, and if your argument list is not too long, consider writing a few redundant replacement statements, passing one character at a time, instead of one line of code that accepts arrays as search and replace arguments.
It's better to use select statements than multi if, else if, statements.
Error suppression with @ is very slow.
Turn on apache's mod_deflate
Close your database connections when you're done with them
$row[’id’] is 7 times faster than $row[id]
Error messages are expensive
Do not use functions inside of for loop, such as for ($x=0; $x < count($array); $x) The count() function gets called each time.
Incrementing a local variable in a method is the fastest. Nearly the same as calling a local variable in a function.
Incrementing a global variable is 2 times slow than a local var.
Incrementing an object property (eg. $this->prop++) is 3 times slower than a local variable.
Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one.
Just declaring a global variable without using it in a function also slows things down (by about the same amount as incrementing a local var). PHP probably does a check to see if the global exists.
Method invocation appears to be independent of the number of methods defined in the class because I added 10 more methods to the test class (before and after the test method) with no change in performance.
Methods in derived classes run faster than ones defined in the base class.
A function call with one parameter and an empty function body takes about the same time as doing 7-8 $localvar++ operations. A similar method call is of course about 15 $localvar++ operations.
Surrounding your string by ' instead of " will make things interpret a little faster since php looks for variables inside "..." but not inside '...'. Of course you can only do this when you don't need to have variables in the string.
When echoing strings it's faster to separate them by comma instead of dot. Note: This only works with echo, which is a function that can take several strings as arguments.
A PHP script will be served at least 2-10 times slower than a static HTML page by Apache. Try to use more static HTML pages and fewer scripts.
Your PHP scripts are recompiled every time unless the scripts are cached. Install a PHP caching product to typically increase performance by 25-100% by removing compile times.
Cache as much as possible. Use memcached - memcached is a high-performance memory object caching system intended to speed up dynamic web applications by alleviating database load. OP code caches are useful so that your script does not have to be compiled on every request
When working with strings and you need to check that the string is either of a certain length you'd understandably would want to use the strlen() function. This function is pretty quick since it's operation does not perform any calculation but merely return the already known length of a string available in the zval structure (internal C struct used to store variables in PHP). However because strlen() is a function it is still somewhat slow because the function call requires several operations such as lowercase & hashtable lookup followed by the execution of said function. In some instance you can improve the speed of your code by using an isset() trick.

Ex.
if (strlen($foo) < 5) { echo "Foo is too short"; }
vs.
if (!isset($foo{5})) { echo "Foo is too short"; }

Calling isset() happens to be faster then strlen() because unlike strlen(), isset() is a language construct and not a function meaning that it's execution does not require function lookups and lowercase. This means you have virtually no overhead on top of the actual code that determines the string's length.
When incrementing or decrementing the value of the variable $i++ happens to be a tad slower then ++$i. This is something PHP specific and does not apply to other languages, so don't go modifying your C or Java code thinking it'll suddenly become faster, it won't. ++$i happens to be faster in PHP because instead of 4 opcodes used for $i++ you only need 3. Post incrementation actually causes in the creation of a temporary var that is then incremented. While pre-incrementation increases the original value directly. This is one of the optimization that opcode optimized like Zend's PHP optimizer. It is a still a good idea to keep in mind since not all opcode optimizers perform this optimization and there are plenty of ISPs and servers running without an opcode optimizer.
Not everything has to be OOP, often it is too much overhead, each method and object call consumes a lot of memory.
Do not implement every data structure as a class, arrays are useful, too
Don't split methods too much, think, which code you will really re-use
You can always split the code of a method later, when needed
Make use of the countless predefined functions
If you have very time consuming functions in your code, consider writing them as C extensions
Profile your code. A profiler shows you, which parts of your code consumes how many time. The Xdebug debugger already contains a profiler. Profiling shows you the bottlenecks in overview
mod_gzip which is available as an Apache module compresses your data on the fly and can reduce the data to transfer up to 80%


Und wers detailliert mag: A HOWTO on optimizing PHP
zorg.ch
#104165 by @ 17.10.2007 13:39 - nach oben -
bahnhof. i weiss nur nonig welle.
zorg.ch
#104174 by @ 17.10.2007 14:32 - nach oben -
95% isch mir klar, öppe bi 99% vo mim PHP-Code hani obiges nöd beachtet, 100% wäred uf Zorg anwendbar zum ziemli sicher ä optimierig vo dä Ladeziite z erreiche.
zorg.ch
#104177 by @ 17.10.2007 14:43 - nach oben -
Achtung, sowas ist gefährlich!

Code-Optimierungen solltest du nur machen wenn du etwas wirklich zeitkritisches hast (z.B. inner loop in nem video encoder/decoder).

Bei allem anderen machen high-level Optimierungen (Stimmt die Programmlogik? Stimmen die DB Indexe?) viel mehr Sinn, weil dann auch der Code lesbar bleibt.

Code-Optimierungen bringen nur sehr wenig Geschwindigkeitsgewinn, scränken aber die Lesbarkeit stark ein. Oder glaubst du wirklich dsa $i++ vs. ++$i IRGENDEINEN Einfluss auf eine pageload time hat?
zorg.ch
#104179 by @ 17.10.2007 15:05 - nach oben -
das vielleicht nicht. aber "Do not use functions inside of for loop, such as for ($x=0; $x < count($array); $x) The count() function gets called each time." bestimmt.
zorg.ch
#104181 by @ 17.10.2007 15:15 - nach oben -
Der ist wirklich gut, ja. ;)
zorg.ch
#104183 by @ 17.10.2007 15:57 - nach oben -
Ich habe kürzlich unser Forum ERHEBLICH optimiert, indem ich die Ausgabe via "echo" anstatt "print" machen liess.
zorg.ch
#104187 by @ 17.10.2007 16:46 - nach oben -
könntest du das auch hier machen?
zorg.ch
#104194 by @ 18.10.2007 08:34 - nach oben -
Das Zorg-Forum ist doch absolut i.O. von der Ladegeschwindigkeit, oder?
zorg.ch
#104195 by @ 18.10.2007 08:54 - nach oben -
i find zorg eini vo de langsame site woni viel bsuech :)
zorg.ch
#104196 by @ 18.10.2007 09:34 - nach oben -
Ach du hast es generell auf Zorg bezogen. Ja, da gebe ich dir recht, deshalb eigentlich auch der ganze Thread. Wobei beispielsweise das Zorg-Forum performance mässig absolut akzeptabel ist, was man von der Startseite nicht behaupten kann.

Ich habe mal mit einem PHP profiling Script die Ursache gesucht und bin aufs Smarty-Modul gestossen. Kürzlich habe ich zusätzlich erfahren, dass Smarty angeblich noch nicht für PHP 5 optimiert ist; sich eigentlich gar nicht lohnt mit aktuellen PHP Versionen zu verwenden. Diesbezüglich muss ich mich aber noch detaillierter informieren.
zorg.ch
#104197 by @ 18.10.2007 09:43 - nach oben -
da bestätigt sich wieder einmal meine smarty-antipathie
zorg.ch
#104201 by @ 18.10.2007 11:15 - nach oben -
Anfang 2008 beginne ich zusammen mit einem Kollegen die Arbeit an einer neuen Version unserer "Clanpage" (vom SWIZZ-Clan). Dabei werden wir garantiert auf ein bestehendes Framework setzen, was sehr wahrscheinlich auch die Nutzung von Smarty erübrigen wird.
Die Erfahrungen aus diesem Projekt könnte ich sicher einbringen um sich dann vielleicht mal langsam eine Zorg V4 (im Moment ist es V3, oder?) zu machen.
Additional posts
zorg.ch
#104605 by @ 13.11.2007 09:15 - nach oben -
Mein ich das nur, oder ist Zorg schneller geworden?
zorg.ch
#104606 by @ 13.11.2007 10:35 - nach oben -
ich hät jetzt glatt das gegenteil behauptet ;-)
zorg.ch
#104612 by @ 13.11.2007 12:31 - nach oben -
gras wächst schneller
zorg.ch
#104188 by @ 17.10.2007 23:11 - nach oben -
Laut Echo Print Doku besteht kein Geschwindigkeitsunterschied.
zorg.ch
#104193 by @ 18.10.2007 08:33 - nach oben -
du hast recht; nichtsdestotrotz war bei mir die Verwendung von echo in der ausgabe eines html-strings erheblich schneller als mit print. Ich bin mir auch ziemlich sicher, irgendwo erst kürzlich noch ein Test print vs. echo gelesen zu haben, wo ebenfalls empfohlen wurde, echo für die Ausgabe längerer Strings zu verwenden.
zorg.ch
#104205 by @ 18.10.2007 18:04 - nach oben -
hm...irgendwie findis verwunderlich das du überhaupt print sache findsch im zorg code....ich han das jedefalls nie verwendet.
zorg.ch
#104185 by @ 17.10.2007 16:00 - nach oben -
Kleinvieh macht auch Mist. Auch Milisekunden summieren sich ;-)