--- Nicht direkt problembezogene Äußerungen ab hier ---
Mag sein das der Gewinn nur minimal ist,
aber jede Optimierung sollte doch benutzt werden oder?
Bedingt. Sobald es die Verständlichkeit (stark) beeinträchtigt, und das Programm nicht nur von einer Person gepflegt werden muss, bin ich strikt gegen übermäßige Optimierung. Die Laufzeiteffizienz ist ein anderer Schuh als die Entwicklungseffizienz - Und letztere sollte immer vorgehen sofern es nötig ist.
Und wir unterhalten uns hier letztenendes über PHP, also bitte...
Wer Zend als Framework benutzt ist in meinen Augen selbst schuld.
Ist in meinen Augen nicht wirklich sinnvoll ein so überzogenes Monster für Otto Normal Projekte zu verwenden.
Gerade dafür bietet es sich meiner Meinung nach besonders gut an. Es ist relativ leicht zu erlernen, transparent und vor allem entwicklungseffizient. Vor allem bei nicht allzu performancelastigen Einsatzgebieten macht es durchaus sinn die eh verfügbaren Ressourcen zu verwenden.
Anders sieht das bei größeren Projekten mit PHP in der Hauptrolle aus: Da werden Data Caching, Opt-Code Caching, Datenbankoptimierung, etc gebraucht, und jedes Zeichen im Code muss im besten Fall richtig sitzen. Für sowas bringt ein unverändertes Framework viel zu viel Ballast mit. Allerdings können Open Source Frameworks mit entsprechenden Anpassungen durchaus sinnvoll sein, da sie erprobt wurden, und nach einem gewissen Quasi-Best-Practice erbaut wurden.
Das alles muss man immer in Relationen sehen: Die Rechentechnik heutzutage bringt die Leistung mit, warum sonst laufen so viele Enterprise Webapplikationen über eine Java VM, und dann häufig auf einem Framework wie Spring, mit Templates auf Basis der JSTL, etc?
Nutzt dein Server nen Query Cache?
Wenn ja, dann kann man das getrost direkt in der Abfrage abarbeiten lassen.
Mir fällt spontan kein deutsches Hostingangebot unterhalb eines VPS ein, welches einen (ordentlichen) Query Cache mitbringt, zumal Caching immer dann kontraproduktiv ist, wenn der Speicher knapp ist. Da bringt der schnellste Speicher nichts, wenn ständig geswappt werden muss. Sicherlich hast du Recht, dass man an vielen Ecken optimieren kann (und vor allem in Sachen Query-Cache macht es natürlich Sinn die selben Abfragen zu verwenden).
Auch kann man für wiederkehrende Abfragen views einsetzen.
Richtig, dafür sind sie ja gedacht. Meiner Meinung nach leidet auf Grund von Views leider aber auch die Verständlichkeit. Und am Ende übersieht man, dass man mit einem View joint, welcher bereits einige Joins umfasst...
Also ist hier der Datenbank Server Meilen schneller als Php. Sorry, so seh ich das.
Datenbanken sind in dem schnell, wofür sie konzipiert wurden: mengen(relationale) Operationen. Vieles lässt sich heute auch komplett in Datenbanken evaluieren, wie laufzeiteffizient das jedoch ist, muss immer erst erprobt werden.
Vor allem problematisch wird es in Sachen Datenbanken immer dann, wenn diese auf einem anderen Host betrieben werden. Da mag das Sammeln der entsprechenden Daten noch so flott ablaufen, aber schließlich müssen auch die Daten hin- und hergeschickt werden, und dann überlegt man lieber zwei Mal was man hinschickt, und was man (in welchen Mengen) zurückbekommen möchte)
Außerdem, woher weißt du ob
Unbedingt immer True ergibt.
Was ist wenn 0, false oder '' drin steht.
Was ist dann?
Ich weiß gar nicht dass das true zurückgibt (Habe ich das überhaupt vorgeschlagen?).
Mag sein, manchmal der weg über die Datenbank hinderlich und langsam ist, aber wenn der Cache erstmal gefüllt ist, läufts schnell.
Vorausgesetzt man hat genügend Cache... Und man muss letztenendes auch bedenken, dass eine suboptimale Konfiguration des Cachings größere Performanceprobleme mit sich bringen kann als kein Caching.
Die wenigsten, die PHP verwenden, haben Zugang (sowohl verständnisbedingt als auch technisch) zu derartigen Themen, und es ist in diesem Kontext auch nicht zweckmäßig.
Außerdem ist jede Schleife / Kondition eine bremse für den Interpreter von PHP.
Wenn du jetzt ne Sprache wie C++ hättest, würd ich dir sofort zustimmen.
Aber nicht bei PHP.
In (imperativen) Rechensystemen sind Schleifen immer Bremsen, das beschränkt sich nicht auf interpretierte Sprachen. Allerdings sind sie nun mal nötig um eine Sprache turing-vollständig zu machen (und dadurch überhaupt erst Rechenoperationen, wie wir sie implementieren, zu ermöglichen).
Wenn man keinen Op Code Cache hat, zieh ich persönlich die Datenbank für Abfragen vor.
Irgendwoher müssen die Daten schließlich kommen. Ob ich aber die Datenbank, und in welchem Umfang ich sie verwende, mache ich nicht davon abhängig, ob ich vom Interpreter interpretierten PHP-Code cachen kann, sondern in wiefern es nötig ist. Die beste Performance erzielt man durch effektives Bereithalten der Daten in schnellem Speicher - Sowohl Opt-Code als auch Daten sollten sinnvoll gecacht werden. Denn irgendwie müssen letztere auch erstmal entstehen. Und es ist (zumindest meiner Vermutung nach) wesentlich schneller die Daten bereits in einem leicht zu interpretierenden Format (zB serialisiert) bereithalten zu können als erst eine Anfrage an die DB zu fahren, deren Antwort dann (meist in einer Schleife) evaluiert und in entsprechende Datenkonstrukte erfasst werden muss.
Und da drückt der Schuh: Es ist eine Sache Benchmarks auf der Datenbank fahren zu lassen, und es ist eine andere Sache PHP zu benchmarken. Und es ist nochmal eine andere Sache beides im Verbund spielen zu lassen.
Ansonsten hält sich das relativ die wagschale.
Mal ist der Php schneller mal MySQL.
Ist also geschmackssache.
Es ist vor allem eine Sache des Einsatzzwecks. Relationale Datenbanken arbeiten gut mit Mengen, PHP arbeitet gut mit imperativen Befehlen.
Wieviele Versionen sind denn noch am Markt?
Die Versionierung von PHP beschränkt sich nicht nur auf eine Ganzzahl, sondern wird in Unterversionen und Releasegruppen (mit und ohne Entwicklungsstand) unterteilt. Ohne es auf Richtigkeit zu überprüfen, behaupte ich einfach mal, dass beispielsweise 5.2.3 und 5.2.9 diverse interne Aufgaben völlig unterschiedlich regeln.
Ich hab noch einen Server wo ich scripte via Benchmark direkt vergleichen kann.
Wo ich Single Quotes und Double Quotes direkt miteinander in diversen Tests vergleichen kann.
Und für mich öffnet sich der Blick, das Single Quotes erheblich schneller sind.
Außerdem wird bei double Quotes der Gesamte String geparsed.
Bei Single Quotes wird der Text als String interpretiert und muß nicht verarbeitet werden.
Um das zu überprüfen, müsste ich erst in die PHP-Sources schauen. Für mich macht es von der theoretischen Betrachtung her aber keinen Unterschied, ob der Interpreter einen sq-String oder dq-String betrachtet, da er sowohl beim einen als auch beim anderen Character-weise drüberwuselt. Lediglich ist die Auswertung bei double quotes umfangreicher, dafür aber auch die Funktionalität.
Aber sollte man nicht immer die Optimalere Variante verwenden?
Was ist optimal?
Ist ein Maximum an Laufzeiteffizienz optimal? Ist eine minimale Arbeit und Mühe, die in die Entwicklung des Programms geflossen sind optimal? Ist es irgendwas zwischendrin? Jede Optimierung muss erst gefunden, entwickelt und erprobt werden. Zudem wird eine Dokumentation erforderlich. Man braucht also somalsorum wesentlich mehr Zeit und Mühe um die Laufzeit zu optimieren, was es betrachtungsabhängig macht, ob man das als optimal bewertet.
P.S.: Ich will jetzt net bösartig klingen, aber das sind meine Erfahrungen. Und ich kenn PHP seit Version 3.
Ditto. Und man schaut auch gerne über den Tellerrand, lernt dazu, und lässt sich eines Besseren belehren. Relevant ist meiner Meinung aber auch, in welche Relationen man das ganze setzt. Interpretierte Sprachen sind nun mal langsamer als compilierte. Auch sind bestimmte Sprachkonstrukte nicht sonderlich schnell. Aber sie machen das tägliche Leben womöglich bequemer und verständlicher, und sollten deshalb nicht in jedem Fall diskreditiert werden.
Soll auch keine Kriegserklärung sein.
So habe ich es auch nicht aufgefasst.
War eigentlich nur gedacht, einem Anfänger in eine gewisse Richtung zu stoßen.
Das ist nett, und hoffentlich fruchtet es auch rechtzeitig.
