Noch wichtiger: Besteht Aussicht, dass sich am Speicherverbrauch was ändert? Wär fein...
Der Speicherverbrauch ist leider schon so gut wie möglich getuned. Das ist letztlich so wie bei normalen PCs: Wenn man die Festplatte mit aller Software vollhaut, ist die Festplatte voll.
Schade... obgleich ich da noch ein paar Ideen habe (siehe weiter unten).
Für Serendipity 1.1 haben wir allerdings an ein anderen paar Ecken Speicher gespart (Smarty Templates belegen jetzt 1/3 weniger Speicherplatz aufgrund von besserer Variablenzuweisung).
Ich hab so einige Hinweise gelesen, dass Smarty für seinen Speicherverbrauch berüchtigt ist.
Ich weiß aber nicht, was an diesen Gerüchten dran ist.
Leider unterstützt PHP es nicht, includete Codeteile nach dem Include wieder aus dem Speicher zu löschen - dann wäre es leichter die Pluginübersicht zu laden.
Ja, richtig. Fiel mir vorhin auch auf.
Die einzige Gegenmaßnahme wäre, die Plugins auf mehrere Quelldateien aufzuteilen.
Die Sessiondaten werden es wohl weniger gewesen sein (Silvia hat da nur mit Serendipity gearbeitet), aber $_SERVER variiert natürlich bei jedem Request, ja. Das erklärt auch, warum immer relativ dicht beieinanderliegende Codezeilen gemeldet wurden.
Falls ihr so etwas nutzt könnte übrigens auch ein APC oder ZendCache solche Schwankungen auslösen.
Nö, hier ist nur FastCgi am Werk.
Es gibt noch eine weitere mögliche Quelle für Speicherlecks: Programmcode, der eine Datenstruktur immer weiter vergrößert, obgleich er die Daten gar nicht mehr braucht.
Also z.B. in PHP, wenn ein Programm immer wieder mit $a[]=... an ein Array anhängt und nie aus $a löscht.
Oder viel Zuweisung mit =& . Das belegt mehr Speicher als die Zuweisung mit =, wenn weder Original noch Kopie verändert werden, aus welchen Gründen auch immer - jedenfalls behauptet php.net, dass dem so sei.
Oder Zuweisung eines großen Arrays (ein paar zehntausend Einträge) mit =, dann Ändern an einem Element - PHP muss dann die Datenstruktur für das Array doch kopieren (die unveränderten Elemente bleiben erhalten).
ah, sowas meintest du. Das fällt bei mir nicht unter "Speicherleck" sondern "Speicherauslastung".
Jein.
Wenn die Daten tatsächlich noch benötigt werden, ist es Speicherauslastung.
Werden sie nicht mehr benötigt, ist es ein Speicherleck.
Die Abgrenzung ist natürlich teilweise Geschmackssache - manche Dinge will man noch im Speicher haben, auch wenn sie (im Moment) von keinem Plugin benötigt werden.
Ich stelle allerdings bei meinem Code immer wieder fest, dass ich Daten rumliegen lasse. Deshalb packe ich meinen Code grundsätzlich in Funktionen (das räumt automatisch das Meiste weg), aber wenn Daten in eine globale Variable übertragen werden, oder wenn eine Funktion praktisch während der ganzen Laufzeit aktiv ist, hilft das natürlich auch nicht - und da passe ich dann ein wenig mehr auf
Tut mir wirklich leid für die Probleme auf beiden Seiten - ich wünschte, man könnte da mehr tun. Plugins nicht mit OOP-Struktur zu entwickeln würde zwar etwas Speicher sparen, dafür aber technisch sowohl unschön als auch weniger flexibel sein. :-/
Na ja... die OO-Mechanik von PHP taugt eigentlich nicht viel. Ich verwende Klassen eigentlich nur, um Namensräume abzugrenzen.
Ganz zu schweigen davon, dass das Konzept "OO" ein ziemlicher Irrweg ist. In PHP5 ist der Mechanismus ja deutlich verbessert, aber damit werden ein paar neue Probleme sichtbar - wenn die PHP-Macher auf diesem Weg weitergehen, ist PHP15 sowas wie Eiffel, bei dem fast alle OO-Probleme überzeugend gelöst sind, und es bleiben die fundamental unlösbaren OO-Probleme übrig und sie stellen fest, dass Funktionen höherer Ordnung erstens diese Probleme nicht haben und zweitens alles Wesentliche können, was OO auch kann... nun ja, Warten auf PHP16 ist für Serendipity sicherlich keine echte Lösung
Flexibilität lässt sich auch durch andere Techniken erreichen. Schau mal auf PmWiki (
http://pmwiki.org), das arbeitet mit diversen Arrays, in denen Template-Strings bzw. Funktionen drinstehen. PmWiki erzielt damit eine Flexibilität, die mich immer wieder verblüfft, und ein typisches PmWiki-Plugin liegt so bei 100-500 Codezeilen (500 Zeilen sind schon richtig viel und realisieren neue Funktionalität).
Ich weiß natürlich nicht, wieviel davon für Serendipity beim jetzigen Stand der Dinge nutzbar ist... ich kenne den Quelltext von Serendipity nicht und habe leider auch nicht die Zeit, mich soweit einzuarbeiten, dass ich da echte Hilfe beisteuern könnte.
24 Stunden am Tag sind einfach zuwenig... ich muss wohl mal die Nacht dazunehmen
Viele Grüße
Jo
