hotti: Variable an eine Klasse binden

Beitrag lesen

hi,

Das hab ich schon verstanden, aber bei PHP verbleibt zwischen zwei Requests nichts im Hauptspeicher.

Logo ;)
Mir gehts jedoch darum, für _eine_ Abfrage nicht ein großes Array in den Hauptspeicher zu legen.

Ein sich selbst füllendes Array für die Anfrage nach nur einem Ergebnis ist nicht gerade ein intentionsgemäßer Gebrauch.

Sorry, Missverständnis: Das Array wird nicht 'gefüllt'. Es ist schon voll ;)

Also bisher habe ich in meinem Bootstrap-Prozess:
$class = $CFG['/index.html']['class'];
Diese Class wird gebraucht, um das Response-Objekt als Instanz eben der Klasse zu erstellen (vereinfacht).

In Zukunft:
Das Array wird 'gebunden', d.h., es ist 'leer'. Ein Code
$class = $CFG['/index.html']['class'];
wird dieses Array NICHT befüllen, sondern nur den Wert zurückliefern.

Du meinst, viele Einzelabfragen (versteckt in einem Array-Zugriff) sind besser als eine einzige Abfrage nach allen benötigten Werten? Hast du das mal gegeneinander gemessen?

Nein. Es gilt, die Balance zwischen Performance und Hauptspeicher zu halten, das ist immer eine Gratwanderung. Freilich gibts fürs Routing nur die eine Abfrage auf die Klasse, logisch, ein Request => eine Klasse.

Wenn es mir nur um das Routing gänge, da wäre das auch ein leichter Tanz auf dem Grat.
Ein Messen (Benchmark) erübrigt sich: Es ist klar, dass sowohl

  • schon eine einzelne Abfrage (Klasse ermitteln fürs Routing)
    als auch (erst recht)
  • eine Iteration (Sitemap) über ein derart an die DB gekoppeltes Array

länger dauert, als hätten wir das Array körperlich im RAM liegen. Nach meiner Erfahrung liegt die Hauptverzögerung jedoch im Connect zur DB. Sofern die Verbindung steht, geht das über prepared Statements sehr performant ab. Dabei ists völlig egal, ob die Abfragen über einen Array-Layer laufen oder über Methoden-Aufrufe.

Es wäre nicht sinnvoll, das Array aus der DB in einem Rutsch zu lesen, weil: Das habe ich jetzt.

Der Hauptgrund, warum ich diesen Layer einbaue: Alles, was an Code hinten dran hängt, bleibt wie es ist ;)

Es wäre nicht sinnvoll, den gesamten Code zu ändern zum Einbau von Methoden-Aufrufen, damit werden DB-Abfragen auch nicht performanter, als über den Array-Layer.

Ergo: Bis jetzt siehts gut aus, wird jedoch noch ein bischen Geficke mit dem Iterator, das ist für mich Neuland, aber ich lerne gerne ;)
In Perl besteht der Iterator aus 2 Methoden, die zu überlagern sind (FIRSTKEY und NEXTKEY) in PHP ist ein Interface zu implementieren mit 5 Methoden.

class TieUrlMap extends ArrayObject implements Iterator  

Bisher auch kein Problem: Es muss möglich sein, dem Array Werte hinzufügen zu können (temporär aber genauso im Zugriff wie Daten aus der DB). Die Values sind übrigens auch wieder Arrays. Es wird auf ein array_merge hinauslaufen, was ich noch implemtieren muss...

Schluss für heute ;)