Leerzeichen und Kommentare im PHP-Code: Kosten die Laufzeit?

[Rolf B]

Hallo Linuchs,

PHP ist ein Interpiler. Oder Compreter? D.h. dein Sourcecode wird in Bytecode übersetzt, die dann von der ZEND Engine interpretiert werden (Standard-PHP, es gibt auch andere Engines, z.B. HHVM von Facebook).

D.h. Leerzeichen und Kommentare kosten Zeit, ja, und zwar genau einmal, wenn die Bytecode-Übersetzung stattfindet.

Bei einer FastCGI Installation ist es nun so, dass der FastCGI Prozess den Bytecode cached. D.h. die Compilierung in Bytecode findet genau einmal statt, und danach sind Spaces, Kommentare völlig egal.

Die Länge von Variablennamen übrigens auch, man könnte ja meinen, durch Variablen wie $i und $j statt $eingabeIndex und $durchlauf Interpretationszeit einsparen zu können.

Anders ist es, wenn PHP als einfacher CGI Prozess oder Apache Modul läuft. DANN wird für jeden Webrequest ein neuer Prozess gestartet, und neu compiliert. Ob es in diesen Szenarien auch Bytecode-Caches gibt, weiß ich nicht.

Tools, mit denen Du den Bytecode vorcompilieren kannst, so dass der Sourcecode auf dem Server gar nicht mehr nötig ist und nur der Bytecode geladen werden muss, gibt es nicht so richtig. Facebook hatte mal HipHop, das haben sie durch HHVM ersetzt. HHVM verwendet Hack als Sprache (PHP Obermenge) und ist - wie PHP - ein Just-In-Time Compiler. Andere PHP "Compiler" compilieren für die .net Runtime. .net Assemblies sind ebenfalls Bytecode, werden aber immerhin zur Ausführung Just In Time in Maschinencode übersetzt.

Also: Bei Tempoproblemem auf deiner Seite (die Du aber erstmal messen musst) kann die PHP Ausführung ein Problem sein. FastCGI wäre die anzustrebende Ausführungsart. Wenn Du isoliert testest, kommst Du mit Sicherheit nicht in Probleme mit Cache-Misses; aber bei einer sehr großen Seite und vielen Zugriffen kann es natürlich passieren, dass der FastCGI Cache nicht reicht und ständig Code verdrängt wird. Ich habe keine Ahnung, ob das irgendwo geloggt wird, aber wenn die Seite ab einer gewissen Userzahl signifikant in die Knie geht, könnte ein Cache-Überlauf eingetreten sein. Man kann dann versuchsweise den Cache vergrößern. FastCGI cached auch Sessions, auch das kann einen Einfluss haben.

Abhilfe gegen Cache-Überlauf schafft weniger Code, d.h. refaktorieren des Codes, finden von Codewiederholungen und Auslagern in Funktionen, aber das ist viel Arbeit.

In den meisten Fällen wird das aber nicht der Auslöser für eine langsame Seite sein. Deine Seite ist datenintensiv, d.h. du solltest mehr Augenmerk auf die DB Zugriffe legen und deren Laufzeit messen, so dass Du mit Indexen oder auch optimierten Zugriffen eingreifen kannst.

Rolf