Prozedurale Programmierung ist tot. Es lebe die prozedurale Programmierung

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.

Jan hat 152 Beiträge geschrieben

8 Kommentare zu “Prozedurale Programmierung ist tot. Es lebe die prozedurale Programmierung

  1. Christoph sagt:

    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.

  2. admin sagt:

    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.

  3. Synthor sagt:

    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

  4. admin sagt:

    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).

  5. Synthor sagt:

    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

  6. js sagt:

    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.

Eine Antwort schreiben

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert mit *

You may use these HTML tags and attributes: <a href=""> <blockquote cite=""> <pre lang=""> <b> <strong> <i> <em>