[Ben]

Dieser Thread hätte genauso gut bei der Literatur angesiedelt sein können.
Ich habe mich aber dazu durchgerungen in an dieser Stelle zu verlinken, da ich ihn für sehr lesenswert halte.

- 40 Tips for optimizing your php Code

Man soll ja generell nicht alles glauben, was so über Performance geschrieben wird, da es häufig auch von der individuellen Implementierung der Anwendungen abhängt. Nichtsdestotrotz zeigt der Blogeintrag von Reinhold Weber durchaus interessante Punkte, die man selbst hinterleuchten kann.

Durch diesen Thread ist natürlich jeder, der meinte weitere nützliche Informationen zu diesem Thema zu haben, dazu aufgerufen diese mit der Gemeinschaft zu teilen.

In diesem Sinne, happy optimizing.

[ljungi]

Das mit dem count() in der for-Schleife wusst ich gar nicht. Sehr interessanter Artikel! Danke, Ben!

Da merkt man mal, wie uneffektiv man doch noch arbeitet :>

[Eyüp]

Danke Ben, im Artikel gibts noch einen Link

http://phplens.com/lens/php-book/opt...ugging-php.php

[mepeisen]

eines vielleicht dazu, da ichs mal überflogen habe.

Auf der einen Seite wird vor der Verwendung von autoload gewarnt, auf der anderen Seite vor require_once.
Wenn man die Wahl hat, Klassen einzufügen und nicht den genauen Pfadnamen kennt (beispielsweise beim Zend-Framework), sollte man einen Autoload-Mechanismus bevorzugen. Denn das Autoload bei einer Klasse ist deutlich effizienter, als in jeder neuen Quelldatei haufenweise teure require_once zu schreiben.

[Basti]

Echt schräge Auflistung, völlig wirr zusammengesammelt. Da findet sich Firlefanz, dazu teilweise noch vielfach widersprüchlich gemessener, wie ' vs. " oder echo vs. print() oder wie eine Ganzzahl inkrementiert werden kann neben Tipps, wie Code in C-Extensions "auszulagern", dem Einsatz von diversen Chaches.

Und dann spricht er och von Profilern. Frag mich, ob der sich wirklich mal das Gewicht seiner einzelnen Tipps angeschaut hat.

Ich denke, hier wäre eine Aufteilung interessant:

1.) Tipps, welche von zwei (oder mehreren) ansonsten gleichwertigen Alternativen schneller ist.

2.) Performance-Tipps, die den Entwurf betreffen - mit Information/Diskussion über die jeweiligen Vor- und Nachteile. Hier wird ja erstmal ungleiches miteinander verglichen und das kann man ja nur individuell auf den gemeinsamen Nenner der Kosten (Mehraufwand an Entwicklung und Wartung bzw. Kosten für Hardware) gebracht werden (wenn das überhaupt für ein "Standard-Projekt" relevant wird). Andere Faktoren, wie der Zeitaufwand für Entwicklung und Wartung pielen da natürlich auch mit rein.

3.) Caching, dass in verschiedenen Ebenen mit keiner bis nur geringer Beeinträchtigung der Architektur des ganzen Gebildes eingebaut werden kann mit seinen Vor- und Nachteilen.

Es macht einfach keienen Sinn, zu schreiben "Error messages are expensive", ohne den Preis zu benennen, da ja a) jeder weiß wie hoch der Preis wäre, Fehlermeldungen aus seinem Code zu verbannen (nämlich letztlich unbezahlbar), b) niemand annehmen wird, dass diese Entscheidung einen wirklich nennenswerten Leistungsvorteil bringen wird und dazu noch c) es jedem Auftraggeber Wurscht sein wird, ob der Besucher eine Sekunde auf seine Fehlermeldung warten muss oder nicht, da es der Fehler ist, der im Fokus seines Interesses ist!

Was ist eigentlich mit der Datenbank?

Basti

[Ben]

Hast schon Recht. Ein Großteil der Punkte ist einfach nur so "reingeworfen" und scheint mir eben dazu zu dienen, um auf möglichste viele Tips zu kommen.

Eine gut sortierte Liste wäre wirklich klasse.

[Orolhawion]

ich hätte da mal ne frage:

inwiefern unterscheidet sich die geschwindigkeit mit der ein skript abgearbeitet wird, wenn man anstelle von
1.

PHP-Code:

public function foobar()
{
   if (bedingung)
   {
      // ...
   }
} 


das hier benutzt:
2.

PHP-Code:

public function foobar() {
   if (bedingung) {
      // ...
   }
} 


?

angenommen man hat viele verschachtelungen, so hat der interpreter ja auch mehr zeilen zu lesen als bei 2.
fällt sowas mit zunehmender anzahl von verschachtelungen ins gewicht oder nicht?

ja, ich könnte einfach mal einen versuch machen und die zeit messen. aber vielleicht hat sich dessen ja schonmal jemand angenommen..

[Ben]

Ich behaupte, dass das nur in äußersten Extremfällen ins Gewicht fällt, ohne es aber jetzt belegen zu können.

Gab vor Jahren auf php.de mal einen Thread zu einem ähnlichen Thema. Da ging es um Performanceunterschiede bei langen Variablennamen. Die dort von mir getätigten Aussagen würde ich allerdings nun nicht mehr so machen. Man lernt ja bekanntlich, ne?

Hier der Link: http://phpfriend.de/forum/viewtopic.php?t=35134

[mepeisen]

Die beiden Beispiele dürften sich nur in einem nicht wirklich messbaren Bereich unterscheiden. Der Parser übersetzt das ganze bereits im ersten Schritt in ein lesbares internes Format, wodurch beide Varianten identisch sind. Der Parser hat statt eines Leerzeichens einen Zeilenumbruch zu interpretieren, wobei aber beides an dieser Stelle als Whitespace behandelt wird, also identisch.

[Ben]

Ich bin nur zufällig auf diesen Blog hier gestoßen, habe also keinerlei Erfahrungen mit der Seite, aber da kann man ja mal mitlesen. Muss ich mal etwas stöbern, wenn ich die Zeit finde.

http://phpperformance.de/