Seit einiger Zeit ist auch PHP OOP-fähig – und das gar nicht mal schlecht inklusive Vererbung, Kapselung und Polymorphie.
Durch die 3 Grundsätze von OOP drücken sich auch die Vorteile davon aus: Code-Teile sollten einfacher wieder zu verwenden sein und Teams können effektiver gemeinsam programmieren.
Dieser Beitrag soll mal genauer beleuchten, wie hoch die Kosten für dieses Plus an Komfort sind, denn es ist ja offensichtlich, dass sich von Maschinencode über Assembler bis hin zu heutigen Programmiersprachen der Komfort beim Programmieren immer weiter verbessert hat – allerdings auf Kosten der Performance. Ist das bei PHP genauso?
Um die Frage zu beantworten haben wir eine einfache Aufgabe zu erledigen: Das Wort „Performance“ soll rückwärts ausgegeben werden. Dazu haben wir (mindestens) drei Möglichkeiten: eine globale Funktion, eine statische Methode in einer Klasse und eine nicht-statische Methode.
// als Funktion function turnLetters($string) { $newString = ""; for($i=strlen($string)-1;$i>=0;$i- -) { $newString .= $string{$i}; } } // als statische Methode class StringFunctions { static function turnLetters($string) { $newString = ""; for($i=strlen($string)-1;$i>=0;$i- -) { $newString .= $string{$i}; } return $newString; } } // nicht-statische Methode class StringFunctions { function turnLetters($string) { $newString = ""; for($i=strlen($string)-1;$i>=0;$i- -) { $newString .= $string{$i}; } return $newString; } } |
Die Geschwindigkeitsunterschiede sind nicht riesig, aber doch bemerkbar. Wenn der Interpreter zuerst das Objekt anlegen muss, wird dafür am meisten Zeit benötigt, aber seht selbst:
| Datei | Gesamtlaufzeit | durchschnittliche Laufzeit pro Durchlauf | Verhältnis zur schnellsten Variante |
|---|---|---|---|
| result_function.php | 12.277654 s | 1.228 ms | 100 % |
| result_ staticmethod.php | 12.658201 s | 1.266 ms | 103 % (+ 3%) |
| result_ nonstaticmethod.php | 12.908561 s | 1.291 ms | 105 % (+ 5%) |
Ein ähnlicher Artikel bei PHP Blogger zeigt ein ähnliches Ergebnis. Ich wollte es nur noch mit nem Benchmark unterlegen.
Zum Nachvollziehen gibts natürlich die eingesetzten Scripte sowie die Benchmark-Ergebnisse.
Hallo,
du hast dich bei allen 3 Beispielen vertippt. Beim ersten hast du $i++, bei den anderen beiden nur $i- 😉
In C++ ist übrigens das Präfix-Inkrement schneller als das Postfix-Inkrement. Ob das bei PHP genauso ist, weiß ich nicht. Lag aber auch nur im 1-Takt-Bereich.
Beim ersten Beispiel hast Du recht, allerdings bei den letzten beiden nicht. Habe festgestellt, dass dieses Code-Highlighting-Paket das — zu einem einfachen – umwandelt (vermutlich der Unterschied zwischen Binde- und Paranthesestrich). Ich hab jetzt ein Leerzeichen dazwischen geschrieben. So ist der Code allerdings leider nicht mehr ausführbar. In den angehängten Quellcodes sollte es aber richtig sein.
Wie hast du die Skripte denn getestet?
Per Unix-Shell und dann mit Time die Laufzeit gemessen?
Im Apache oder einem anderen Webserver würden die Skripte wohl noch einen Ticken langsamer laufen. 😉
Greets Synthor
Ich habe die Scripte – wie alle anderen Benchmarks auch – mit dem Benchmark-Tool von Apache (ab.exe) getestet. Ich denke nur dadurch bekommt man wirklich aussagefähige Zahlen (im Gegensatz zum Test mit PHP selbst).
Ah, gut zu wissen. 😉
Jetzt wäre ja noch der Vergleich vom Apachebenchmark zum Benchmark mit Time in der Shell interessant.
Vielleicht als kleine Anregung an dich…
Greets
Kann ja verstehen, dass Ihr alle oop feiert. Aber für den Durchschnittsprogrammierer finde ich die prozedurale Programmierung einfach lesbarer und auch viel einfacher. Oder bin ich einfach nur Grottenschlecht.
Naja macht ja nichts. ich mit meinen 60 Lenzen werde mir das nicht mehr antuen.
Ich entwickele jetzt seit rund 20 Jahren, davon seit rund 15 Jahren mit OOP und ich bin froh, zu einem Zeitpunkt in PHP eingestiegen zu sein, in der OOP noch nicht die Freiheit der Entwicklung behindert hat.
Denn das tut es: OOP schränkt ein, ganz drastisch und unheimlich. Es werden immer die selben Lösungsansätze verwendet – in Stein gemeißelte Lösungsmuster und Probleme die durch sie verursacht werden, sollen mit den selben Mustern gelöst werden.
Dabei kommen teilweise 4000 Zeilen Quelltext für Aufgaben heraus, die man in 4 Zeilen gelöst hätte – ohne OOP – aber die sind dann wiederverwendbar, natürlich auch im Projekt selber und für weitere Projekte auch (wenn die Zeilen dann noch einer versteht. Na gut, übersichtlich sind die ja die 4000 Zeilen. Die verteilen sich auf schlanke 400 Dateien und die 200 Seiten Dokumentation erleichtern einem die Arbeit auch ungemein).
Wenn man Jahre in einer Parallelwelt gearbeitet und sich dann rund 3 Jahre wieder in die „neuesten“ Errungenschaften (wie ORM und MVC) eingearbeitet hat, fällt es einem wie Schuppen von den Augen.
Man ist nicht blöd, wenn man OOP nicht versteht. Auch wenn man sich blöd vorkommt. Man versucht es nur falsch. Man soll gar nicht verstehen „warum oop“.
Man soll fragen „wie“.
Es grenzt quasi an Blasphemie an der Existenzberechtigung von OOP zu zweifeln.