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

[Rolf B]

Hallo Gunnar,

Schlechter Plan.

Ich möchte Dir ja zustimmen, aber ein Hinweis kribbelt mir doch in den Fingern.

Die Qualität des Plans hängt an den Umständen. Wenn der Server auf dem letzten Loch pfeift, ist eine Auslagerung von Rechenzeit auf die Clients eine Möglichkeit, den Service aufrecht zu erhalten. Desktop-Clients sind auf jeden Fall schnell genug, und ich würde behaupten: die meisten Kleingerät-Clients sind es heutzutage auch.

"Extrem schnelle Webseiten" sind natürlich ein anderer Anspruch, d.h. in dem Fall wäre die Alternative "zweiter Server" zu betrachten. Und die Frage zu prüfen, wo sich auf dem ersten Server eine Optimierung des vorhandenen Codes und der DB (Design+Queries) lohnen kann. Dafür braucht es gründliches Profiling.

Der schnellste Server hilft aber nichts bei einer dünnen Leitung, und fertiges HTML bedeutet auch viel Datentransfer. Trotz GZIP Transfer ist ein reiner Datenbatzen kleiner als aufbereitetes HTML. Die vorher genannte JSON Idee konterkariert das etwas; wenn man da zwanghaft das Datenvolumen minimieren will, muss man wohl vor der JSON Serialisierung noch die Objekte in reine Arrays verwandeln, so dass [ 1, 2, "Foo", "Bar ] über die Leitung geht statt { id: 1, parentId: 2, name: "Foo", givenName: "Bar" }. Selbst die Objekt-Version ist immer noch viel kleiner als das HTML-Fragment für dieses Objekt. Keine Ahnung, wieviel Bytes man spart, aber 200 Bytes pro Satz sind bei 1000 Sätzen 200KiB. Auch da gilt jedoch: Messen, Übertragungsvolumen beobachten, und überlegen, was sich lohnt.

Es dürfte auf jeden Fall effizienter sein, den JSON String ins HTML hineinzurendern statt ihn - wie ich vorher mal andeutete - per XMLHttpRequest separat abzuholen. Aber da hatte ich die Problemstellung anders verstanden.

Rolf