OOP: Performance-Frage

[nohfreak]

Moin Leute,

die frage ist vermutlich trivial, und der Unterschied wird wenn überhaupt, dann nur marginal vorhanden sein, aber ich stelle sie trotzdem mal:

Ich habe ein Objekt, bei dem ich nicht immer alle Felder brauche, und diese demzufolge auch nicht immer alle mit Daten gefüllt sind.

Nun stellt sich mir die Frage, ob es nicht sinvoller wäre dem Objekt anstatt mehrerer Datenfelder mit:

private Feld1;
private Feld2;
private Feld3;
etc. 

Nur ein Datenfeld mit einem Assoziativen Array zu geben.

Ich denke mir dabei, dass ja durch das Instanzieren eines Objekts im Speicher durch das Deklarieren der Felder Platz reserviert wird für einen Verweis/Zeiger.

Wenn ich nun von 20 Feldern aber in manchen Fällen nur 5 Felder brauche, und somit die anderen garnichterst vollmache, dann wären die 15 Felder doch vergeudeter Speicher, oder sehe ich das falsch ?

Evtl. verbraucht das Handling eines Arrays ja noch mehr Speicher, oder erhöht merklich die Laufzeit,....

Ich weiß es nicht.

Ich hoffe ich konnte meine Frage so formulieren, dass ihr wisst, was ich eigentlich meinte.

Ist das generell Unsinn sowas, oder macht das doch irgendwie Sinn ?

Danke schonmal.

Gruß,
Nohfreak

[PHP-Desaster]

Interessante Frage. Ich habe das gerade mal - total simpel und nicht sehr aussagekräftig - ausprobiert und hatte als Ergebnis, das ein private Member mit einem Array von 50 Werten deutlich kleiner ist, wie eine Klasse mit 50 private Membern. Siehe dazu auch das Skript im Anhang. Danach ist eine Instanz der Klasse A 3208 Byte groß, eine Instanz der Klasse B nur 200 Byte. Probier einfach selbst ein wenig herum, um "echte" Ergebnisse zu bekommen.
Der Unterschied ist wirklich verblüffend. Doch ich denke, das ist hier keine Entscheidung des Speichers, nach der du deine Klassen aufbauen solltest, sondern eine Frage der Übersichtlichkeit und Wartbarkeit. Eine Instanz mit den Membern 'title', 'description' und 'link' ist definitiv leichter verständlich wie eine Instanz mit dem Member 'data'.
Vielleicht kann diesen Verbrauch jemand mit Kenntnissen des PHP-Sourcecodes etwas näher erläutern.

[fireweasel]

Original geschrieben von PHP-Desaster
Interessante Frage. Ich habe das gerade mal - total simpel und nicht sehr aussagekräftig - ausprobiert und hatte als Ergebnis, das ein private Member mit einem Array von 50 Werten deutlich kleiner ist, wie eine Klasse mit 50 private Membern. ...

Könnte das daran liegen, dass die Eigenschaft "private" ja irgendwo gespeichert werden muss, und eine "private property" daher weniger Speicher belegt als 50?
Unter PHP4 gabs diese Eigenschaften noch nicht, möglicherweise war dort der Speicherverbrauch (annähernd) gleich.

[combie]

Wenn ich nun von 20 Feldern aber in manchen Fällen nur 5 Felder brauche, und somit die anderen garnichterst vollmache, dann wären die 15 Felder doch vergeudeter Speicher, oder sehe ich das falsch ?

Oha..
Das ist ein Indiz dafür, dass du versuchst ein God-Objekt zu schaffen.
http://de.wikipedia.org/wiki/God_object

[PHP-Desaster]

Könnte das daran liegen, dass die Eigenschaft "private" ja irgendwo gespeichert werden muss, und eine "private property" daher weniger Speicher belegt als 50?

Kann mir das auch nur so erklären. Aber wie schon gesagt, wenn OOP, dann bitte auch richtig In der Verwendung der Klassenmember versuchen zu optimieren, indem diese durch Arrays ausgetauscht werden ist geradezu absurd. Da schießt du mit einem dusseligen SQL-Statement einen Haufen mehr Speicher ab.

[nohfreak]

Eigentlich bastel ich mir gerade eine Klasse zur User-Verwaltung.
Und da braucht man eben nicht auf jeder Seite alle Eigenschaften, die ein User theorethisch haben könnte.

Wäre dann ja Unsinn die immer z.B. im Konstruktor alle aus der DB zu holen und zu initialisieren, oder seh ich das falsch ?

Ich tippe darauf, dass die private Members mehr Speicher brauchen aus folgendem Grund:

Bei JAVA z.B. weiß ich, dass es so ist, dass eine Variable lediglich ein Verweis auf einen Ort im Speicher ist. Dementsprechend hätte jedes Member einen anderen Verweis und verschiedene Orte im Speicher.

Das Array hätte nur einen Verweis, der auf ein zusammenhängendes Stück Speicher ( "Speicherfläche" ) verweist,

Wenn das bei PHP auch so ist, dann könnte das evtl. des Rätsels Lösung sein.

Aber anscheinend ist das zu vernachlässigen, der Übersichtlichkeit halber ? Aber mit dem Array wärens immerhin 15x weniger Speicher. Das ist schon nicht ganz ohne bei großen Projekten würde ich vermuten, vorallem, wenn man begrenzte Ressourcen hat.

[unset]

Original geschrieben von nohfreak
Aber mit dem Array wärens immerhin 15x weniger Speicher. Das ist schon nicht ganz ohne bei großen Projekten würde ich vermuten, vorallem, wenn man begrenzte Ressourcen hat.

Die ersparten Kosten gibst du dann allerdings für die Logik wieder aus, die herausfinden soll, was du brauchst und dann nur das lädt. Der Gewinn ist also alles andere als beträchtlich.

[combie]

Ach... du fummelst am falschen Ende rum ....

Teil dein Usermodell in 2 Stücke.
Usermodell UserProfilmodell
Fertig ist die Laube!

Es macht keinen Sinn das ganze Gedöns zu laden, obwohl man es doch nur sehr selten braucht. Wenn es wirklich geladen werden muß, dann eben nachladen.
Auch ist der Unterschied ob 5 Felder oder 15 noch in der Kategorie "wurscht"!
PHP hat normaler weise 8 bis 32 MB zur Verfühgung. Wieviele User passen da rein? Richtig: Massig!

Wenn du dir um solche Kleinigkeiten einen solchen Kopf machst, steht zu befürchten, dass woanders die fetten Bocke hängen.

Wie lädst du deine Klassen?
Alle direkt per include/require oder per SPLAutoload?

----------
PHP4 mit PHP5 vergleichen zu wollen, ist auch, naja, unglücklich:
PHP 4 ist gestorben und kommt auch nicht mehr wieder
Die ZendEngine ist komplett ausgetauscht worden

[nohfreak]

Ich lad die Klassen so:

function __autoload($class){
        require 'lib/' . $class . '.class.php';
    } 

Aber momentan hab ich noch garkeine Probleme, ich hab mir nurso meine Gedanken gemacht.

Danke an alle, die geantwortet haben.

[combie]

Damit ist die Resourcenverplemperung schon mal eingegrenzt!

Aber, wie gesagt: Ich empfehle dir den SPL Autoloader.
Weil, von deinem darf es nur einen geben, SPL Autoloader viele!

Auch könntest du dich an das PEAR/Zend Benennungsschema halten. Dann wärst du mit einem großen Teil der modernen PHP Software Welt kompatibel. Muß ja kein Fehler sein...

Dein User Modell bekommst du bei google("Doctrine ORM") quasi geschenkt. Zumindest einen Seitenblick ist es wert.

[nohfreak]

Ähm, also ich muss gestehen ich bin ziemlicher Anfänger, was OOP angeht, ich hab nach dem "SPL Autoloader" mal gegoogelt, aber das ist nicht wirklich was rumgekommen, das mir näher gebracht hat was das ist, und wie es funktioniert, für 1-2 erläuternde Sätze wäre ich sehr dankbar.

Den Codeschnippel da oben habe ich übrigens von Peter seinem OOP5 Tutorial, was ist dort denn schlecht dran, an der Benennung ?

[combie]

OK:


Angenommen du hast einen Ordner "lib" wo du alle deine Klassen reinstopfst.

Eine Beispielklasse möge heißen: Combie_User

Dann lege einen Ordner in lib an: Combie
Also: ./lib/Combie
Darin eine Datei namens User.php
Mit dem Inhalt:

class Combie_User
{
  // irgendein blödsinn
} 

Der komplette Pfad der Datei lautet also: ./lib/Combie/User.php



In den Ordner lib werfen wir dann auch noch den SPL Autoloader LibAutoload.php:

class LibAutoload
{
  public static function autoload($name)
  {
    $dirname  = dirname(__FILE__);
    $fileName = str_replace('_',DIRECTORY_SEPARATOR,$name).'.php';
    $file     = $dirname.DIRECTORY_SEPARATOR.$fileName;
    if (is_readable($file)) require_once $file;
  }

  public static function register()
  {
    spl_autoload_register(array(__class__,'autoload'));
  }
} 

Dein Hauptprogramm könnte dann so aussehen:

error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', TRUE);



require_once "./lib/LibAutoload.php"; // autoloader laden
LibAutoload::register(); // einbinden



// frisch und frölich nutzen

$u = new Combie_User;
// tuwas mit u 

Dazu bitte lesen:
http://framework.zend.com/manual/de/...nventions.html Zend_Benennungsschema
http://pear.php.net/manual/de/standards.naming.php PEAR1_Benennungsschema

[nohfreak]

Ah, okay, danke dir für die ausführliche Erklärung. Wenn ich das nun richtig verstehe, dann dient diese Namens-Konvention und der Loader nur der besseren Übersicht. Oder ?

Oder bringt dieses SPL auch Performance-Vorteile mit sich gegenüber meinem vorherigen Autoload ?

[combie]

Nein, es bringt keine Performance!
Die Übersicht, ist eine positive Nebenerscheinug.

Aber es ermöglicht dir die parallele Nutzung weiterer Autoloader wie sie z.B. im Zend Framework oder in Doctrine eingesetzt werden. Bei deinem Autoloader ist das nicht möglich. Da würde sich das Gedöns in die Quere kommen.... Du verhinderst/erschwerst damit die Integration deiner Scripte/Klassen in fremde Projekte. Und umgekehrt.
Willst du das?

Dein Weg ist also eine Insellösung, der über SPL entspricht einer (stillschweigenden) Übereinkunft der wichtigsten PHP5 Software Produzenten.

Tipp:
Wenn du noch die Wahl hast, dann schwenke um!



[Edit:]
@ Mr. Peter Kropff
Falls du das lesen solltest und es dir zusagt, dann nimm es doch bitte in dein Tutorial auf. So werden dann noch mehr OOP Anfänger auf den "rechten" Weg gebracht.

[ezkimo]

Okay das mit der SPL Autoload Funktion ist ziemlich genial. Der Vorteil liegt natürlich für OOP auf der Hand und ich konnte diesen wertvollen Tipp bereits umsetzen. Danke an dieser Stelle schon mal.

Leider habe ich ein Problem. Ich programmiere gerade ein Plugin für eine Software, die bereits eine __autoload() Funktion besitzt. Die Funktion spl_autoload_register() scheint die bestehende __autoload() Funktion der Software zu übrschreiben. Das Manual sagt dazu folgendes:

If your code has an existing __autoload function then this function must be explicitly registered on the __autoload stack. This is because spl_autoload_register() will effectively replace the engine cache for the __autoload function by either spl_autoload() or spl_autoload_call().

Soweit alles schlüssig. Wie registriere ich nun spl_autoload_register() im __autoload Stack? *grübel*