Flor1an

Ich versteh die ganze Diskussion nicht wirklich. Caching ist einfach in bestimmten Situationen absolut nötig.

Ein paar Beispiele:
- Normalisierte Datenbanken: Hier sind Daten über viele Tabellen verstreut, die auszulesen dauert deutlich länger als wenn diese Daten nicht normalisiert in der DB liegen würden. Aber, wie wir alle wissen, sollten wir möglichst nicht auf Normalisierung verzichten. Vor allem wenn verschiedene Applikationen auf die Daten zugreifen sollten sie normalisiert sein. Wenn dann eine Anwendung sehr komplexe Abfragen generiert können wir am Schema nichts verändern und müssen so die Daten zwischenspeichern.

- Webservices: Angenommen die Daten die du lädst kommen nicht von deinem eigenen Server sondern von Webservices oder von anderen Servern die in einem ganz anderen Netzwerk stehen. Hier ist auch Caching nötig um das ganz performant zu halten.

- DB Master/Slaves: Die Slaves sind im endeffekt ja auch nur ein Cache.

- CPU: L1, L2, Arbeitsspeicher -> alles Caches ohne die rein gar nichts funktionieren würde.

Jetzt erzählt mir mal einer wie man sowas mit guter Projektplanung von vorne rein unterbinden will.

Mister Ad

Wolfsblut

Wer sagt denn, dass dies Caching ersetzen würde?

Caching hat seinen Platz.

Doch manchmal ist ein Cache nicht möglich.

Und manchmal muss ein Cache auch erzeugt werden.

Und manchmal muss er sogar noch verwaltet werden.

Performance-Gewinn schlägt sich ja nicht nur allein in zunehmender Geschwindigkeit nieder...weshalb ein grundsätzlicher Augenmerk darauf ja nie verkehrt ist - solange das nicht in Mikro-Optimier-Endlos-Schleifen endet, sondern in einem ganz natürlichen erlernten Verhalten.

Wenn ich mir so manchen Programm-Code ansehen, passieren da oft schlimme Dinge, weil Alternative nicht verinnerlicht wurden.

Objektivieren des ganzen machst immer noch für die Branche Sinn.

Dormilich

Halte ich letzten Endes auch für praktisch sinnvoller. Man vergeudet mehr Zeit durch ungünstige Strukturen (z.B. Berechnung von Schleifenabbruchbedingungen) als durch andere Funktionen (mal abgesen von Sachen wie "benutze nicht preg_match() wenn's auch strpos() tut").

Und nochmal zum Thema Cache, da würde ich eher in der Einleitung drauf eingehen, da caching zwar die Response-time verbessert (Ergebnis ist ja schon da) aber kein eigenes Ergebnis erzeugt und in dem Sinne sich gar nicht mit "ungecachtem" Code vergleichen läßt.

meikel

Um was gehts? Ach ja: um den Cache.
Iwo denn...
man nehme einfach einen i32 Prozessor mit 320GHz, 1TB RAM, 10Gbit Netzwerkkarte und ne Super Talent RAIDDrive II als Cacherechner und den großen Bruder davon als LAMP System. Und auf dem Schlachtschiff kannste dann jedes noch so langweilige und aufgeblasene PHP Monster äh... "Script" bei 150 gleichzeitigen Klicks in einer akzeptablen Laufzeit abspulen lassen.

Dumm nur, wenn man sich mit weniger begnügen muß... <rotfl>

mermshaus

Eigentlich wollte ich mit dem Aufgreifen des Caching-Themas vorhin bloß einen dummen Witz machen, weil wir uns deshalb im Threadverlauf so sehr in den Haaren hatten. Ich glaube, Caching ist sehr relevant für generelle Performance-Überlegungen (auch etwas Definitionssache des Begriffs – man kann das sehr weit fassen), aber wenn das nicht Maggi76s zentraler Punkt werden soll, sollten wir vielleicht versuchen, uns nicht wieder zu sehr auf das Thema einzuschießen. Sorry, dass ich damit wieder angefangen habe.

Da mein letzter Post eventuell zu einseitig war: Man kann natürlich schon generelle Überlegungen und Vergleiche zur Performance von bestimmten PHP-Funktionen anstellen. Das ist sicherlich auch nicht generell unsinnvoll, wie es Wolfsblut und Dormilich ja auch geschrieben haben.

Die Schwierigkeit besteht aber darin, die allgemeinen Aussagen zu konkretisieren beziehungsweise für einen bestimmten Anwendungsfall nutzbar zu machen. So was wird es vor allem nicht sein, was für „30 % Performance“ verantwortlich ist. Ich denke, die meisten PHP-Skripte haben eine geringe Anzahl an Flaschenhals-Operationen, die durch den Austausch von Funktionen kaum zu beschleunigen sind, wenn sie nicht gerade ungeschickt programmiert waren. Das Drumrum ist dann wirklich Mikrooptimierung.

Ich sehe ganz ehrlich keine Chance, das sauber hinzukriegen. Und ja, ich habe schon Benchmarks manipuliert.

Zudem sollte man dann eigentlich den C-Code analysieren, in dem die Funktionen verfasst sind. Wobei sich das eben schnell in Aussagen zur Komplexität erschöpfen dürfte.

__________________
Blog | Buch | Kaloa

meikel

1. so dumm war der nicht
2. gern gelesen

Keine Sorge. Mein Text ist Satire.

Da muß ich leider passen. Wärs Pascal, könnte ich noch mitreden, aber bei C/C++ bin ich leider überfragt. Wäre das anders, hätte ich mich schon länst zum Wanzensuchen in den PHP Quelltext gestürzt.

Maggi76

Ich weiß das es unendlich viele Möglichkeiten gibt die man hier mitaufnehmen kann und Caching ist bestimmt auch sehr interessant.
Dazu schreibe ich etwas im Grundlagenteil meiner Bachelor-Arbeit.

Das Problem meiner These ist oder besser gesagt die Vorgabe der Uni ist es etwas zu vergleichen bzw etwas zu untersuchen. Später im Fazit soll die These belegt oder wiederlegt werden. Also genau bedeutet das wenn ich später keine 30% Performnacestigerung erhalte ist das halt nicht schlimm. Sondern ich habe einfach nur bewiesen mit meiner Untersuchung das durch eine Microoptimierung kein 30% Steigerung zu realisieren ist.

Es spielt keine Rolle ob es sinnvoll ist oder ob andere Optimierungsmöglichkeiten besser geeignet sind. Es ist alles nicht das Thema der Bachelor-Arbeit.

Mir ist auch klar das wenn ich eine Anwendung optimiere ich nicht anfange PHP-Funktionen zu optimieren. Sondern erst durch einsetzen von Testsoftware herausfinde wo sich die Bottlenecks befinden.

Daher ist auch mein Ziel endlich Schluß zu machen mit dem Thema "Ob Microoptimierung Sinn macht oder nicht." Daher habe ich das Thema gewählt um es offiziell zu untersuchen in meiner Bachelor-Arbeit.

Dormilich

ich wette einen halben Kasten Bier daß Mikrooptimierung nicht mehr als 10% Steigerung realisieren kann! (um mal eine handfeste Aussage zu machen)

Maggi76

10% nach meinen persönlichen Einschätzung ist schon sehr hoch gegriffen.
Ich denke so um die 1-3%

Wie sehen es die anderen? Was schätzt ihr?

Dormilich

ohne wetten sage ich < 1%. (gegen 1x XML parsen oder externe Datenbanken kommt keine Mikrooptimierung an)