ABAKUS

In meinen Augen ist PHP eh nicht für OO gut geeignet, da du bei jedem Request ja die ganze Applikation startest. Auch wenn das Zend Framework wirklich toll ist und viele bewährte Konzepte (vgl. Servlets) für PHP bringt, du mußt eben für einen Request einmal durch den kompletten Lifecycle.
Deswegen macht Singleton hier auch nur bedingt Sinn.
Kommt eben auf den Einzelfall an, pauschal kann man da wenig sagen.

Ich finde schon, dass ein Singleton in PHP Sinn macht und objektorientierte Programmierung lohnt sich ab einer gewissen Projektgröße immer.

Ich hole mir und verwalte über ein Singleton Pattern sämtliche Klassen und deren Objekte. Schon allein die Tatsache, dass nicht bei jedem Seitenaufruf sämtliche unnötigen Klassen instanziert werden, macht das Singleton so wertvoll. Durch die (in meinem Fall) statische Adressierbarkeit muß man hier auch keine Objekte an andere durchreichen. Das macht die Sache doch sehr interessant und angenehm.

Es kommt dabei aber auch sehr auf den Einsatzzweck an - 1,3MB pro Aufruf empfinde ich jedoch schon als sehr heftig! Hier steckt wohl ein mächtig gewaltiger Overhead drin (ich gehe von einem CMS oder ähnlichem aus).

Grüße

everflux hat geschrieben:In meinen Augen ist PHP eh nicht für OO gut geeignet, da du bei jedem Request ja die ganze Applikation startest. Auch wenn das Zend Framework wirklich toll ist und viele bewährte Konzepte (vgl. Servlets) für PHP bringt, du mußt eben für einen Request einmal durch den kompletten Lifecycle.

Ohne jetzt über das schreckliche Zend fluchen zu wollen:
Wenn die fehlende Persistenz dein Hauptargument gegen Objekte ist: Das geht durchaus. Packe sie einfach in den Speicher.
https://de.php.net/manual/en/ref.sem.php

Das Problem generell ist aber (und zwar in _jeder_ Sprache), dass Objekte auf Grund ihrer höheren Abstraktion mehr Speicher und Rechenaufwand benötigen. Dafür sparen sie sehr viel Zeit im späteren Verlauf der Entwicklung. Solange man keine zeitkritischen Systeme schreibt, kann man sich also auf die immer schnelleren Rechner verlassen oder aber mit Profiling gezählt Flaschenhälse ausmerzen.

Danke fuer die Antworten. Das ganze ist eine Art Social-Network-Dingens. Bei jedem Aufruf werden mehrere Klassen geladen, die alle auf zwei Basisklassen aufbauen. Also muss ich mich demnaechst wohl auf die Suche machen, wo die grossen Speicherfresser sitzen

Wenn Du Dich auf die Suche machen willst, hier zwei ggf. hilfreiche Links zum Thema Caching und Profiling:

https://blogs.reucon.com/srt/2007/12/13 ... tions.html

https://everflux.de/zend-framework-und- ... ching-454/

Danke fuer die Links, werd ich mir ansehen!

Hm, nun habe ich mir grade mal den Speicherverbrauch von phpBB3 angesehen. Ein noch praktisch leeres Board ohne Mods nutzt immer ueber 5MB pro Seitenaufruf. Also liege ich mit 1.3MB vielleicht gar nicht so verkehrt?

Ich finde 5 MB Speicherbedarf nun nicht gerade viel.
Wenn ich mir anschaue, was eine Applikation unter windows sich so krallt.
ituneshelper.exe: 13mb (keine gui)
tpshocks: 5mb (auch ohne gui)
Da darf so ein Forum von mir aus auch 20 MB Speicher benötigen. Das Problem ist ein ganz anderes: Solange Zugriffe über Prozesse abgebildet werden, hast du da nen fiesen Faktor drann. Bspw: 20*5 MB. Dazu kommt dann noch der jeweillige Webserverprozeß und die eingebauten Module, zack bist du bei 20*20 MB.
Lösung in meinen Augen: Nicht anfangen die PHP Anwendungen komisch zu programmieren, sondern die Umgebund umstellen. Oder gleich von PHP weg gehen

Nur unter Windows (oder in meinem Fall Ubuntu Linux) werden solche Anwendungen nicht pausenlos neu kompiliert und gestartet (in meinem Fall hat der Server auch noch PHP als CGI laufen, nicht als Apache-Modul). Da mein Server aber schoen gross ist, und die Besucherzahl nicht in die zehntausende geht, sollte es geschwindigkeitsmaessig (noch) kein Problem sein.

Hatte mich nur sehr ueber den Unterschied zu meiner vorherigen Anwendung gewundert, die eben nur ein paar hundert kB braucht um das gleiche zu machen. Bin auch nur Hobby-Programmierer

Wenn das so ist, würde ich mir wirklich nochmal den ersten Blogbeitrag genauer zu Gemüte führen, da gehts genau darum