Soll man variablen + arrays am ende löschen?

[RamonaS]

Hallo,

In einigen php scripten istz mir aufgefallen, daß der eine oder andere am ende des scripts variablen oder daten köscht:

unset($var1,$var2,$array1,$array2); 

Jetzt wollte ich mal fragen was da der sinn drin ist.
Gibt das dann beim provider wieder etwas RAM frei oder ist das gut um datenklau zu verhindern?

Bei einigen scripten nutze ich das gelegentlich auch. Da wende ich allerdings dieses unset am script-start und am script ende an.
Am start - damit ich sicher bin die dinger sind leer und am ende einfach mal so weil das andere auch tun.

Kann man mit unset alles richtig löschen, also strings, variablen, arrays und sessions oder ist für unset nicht für alles geeignet?

[unset]

Eigentlich wird das alles durch die Garbage Collection geregelt. Schaden tut's trotzdem nicht.

[piratos]

PHP: unset - Manual

Ich setzte es da ein wo es sich wirklich lohnt - also richtig RAM frei wird, ansonsten nicht, denn auch das kostet Zeit.

[PHP-Desaster]

Wenn du deine Prozesse in vernünftige Funktionen gliederst kannst du drauf verzichten, da beim Verlassen einer Funktion erstmal die lokalen Variablen verworfen werden. Ich benötige unset nur für das Entfernen von Arrayelementen.

[onemorenerd]

unset() am Scriptanfang bringt nichts.*

PHP ist nicht C. Du bekommst niemals einen alten Wert aus einem früheren Scriptlauf zu sehen. Bis zum ersten Schreibzugriff ist der Wert einer Variablen Null und danach ... egal.
In der Zend Engine steckt eine Speicherverwaltung (eigentlich die Variablenverwaltung), die genau weiß ob eine Variable schon gefüllt wurde und nur dann wurde ihr überhaupt ein Stück Speicher zugeordnet, aber eben auch direkt überschrieben. Es gibt keine Allozierung ohne direkt folgendes Write.


*) Außer Warning undefined variable ...

[piratos]

Am Scriptende löschen bringt nichts.

Innerhalb eines Scriptes ändert es den tatsächlichen Bedarf.

Beispiel:

Einlesen einer Datei mit 17918 Bytes innerhalb eines Scriptes.

Ohne löschen der Variable nach dem Lesen:

Verbrauch normal:108616 Verbrauch Spitze:262144

Mit löschen der Variable nach dem Lesen:

Verbrauch normal:90952 Verbrauch Spitze:262144

Der Löschorgang selbst verballert also über 300 Bytes.

Besteht die Variable aus einem Object und die Inhalte selbst aus Objecten kann das ganz anders aussehen mit bis zu 0 Wertschöpfung - muss man probieren.

[PHP-Desaster]

Gehört eh alles in den Bereich Mikroperformance, ist also der Rede nicht wert.

[piratos]

Gehört eh alles in den Bereich Mikroperformance, ist also der Rede nicht wert.

So ist es fast, eine gute Gesamtperformance besteht allerdings immer aus extrem vielen kleinen Dingen und selten aus einem einzigen großen Wurf.

[onemorenerd]

Nach Paretoprinzip verschlingen 20% des Codes 80% der Laufzeit.
Mit einem Profiler bekommt man schnell heraus was die 20% sind.
Und wenn man sie optimiert hat, gilt das Prinzip immernoch.

Irgendwann rechnet sich die Optimierung nicht mehr. Die Performancegewinne werden immer kleiner, die Kosten für die Codeoptimierung größer.

À propos Kosten: zusätzliche Hardware ist billiger als Entwicklungsarbeit. Deshalb wird meist zuerst versucht, Performanceprobleme mit Hardware zu erschlagen. Deshalb sollte man auch bei kleinen Applikationen so programmieren, dass sie auf einer Serverfarm laufen kann.

[piratos]

Mit einem Profiler bekommt man schnell heraus was die 20% sind.
Und wenn man sie optimiert hat, gilt das Prinzip immernoch.

Irgendwann rechnet sich die Optimierung nicht mehr.

À propos Kosten: zusätzliche Hardware ist billiger als Entwicklungsarbeit. Deshalb wird meist zuerst versucht, Performanceprobleme mit Hardware zu erschlagen. Deshalb sollte man auch bei kleinen Applikationen so programmieren, dass sie auf einer Serverfarm laufen kann.

Auch das ist richtig was insbesondere mit Profilerarbeit schnell zu erkennen ist.

Aber nicht jeder kann und will in Hardware investieren.
Das gilt gerade für den Opensourcebereich.
Dort werden Serverplätze häufig nach dem geringsten Preis ausgesucht und / oder man scheut einfach den Umstieg auf eine bessere Hardware sprich besseren Serverplatz.

Nach den ersten 20% kommen andere 20%.
Die Verbesserungsmöglichkeiten ohne Strukturänderungen sind dann tatsächlich irgendwann nur noch marginal und das man dann mit erledigen, wenn man da irgendwo in Codenähe ist oder man lässt es, weil es sich nicht lohnt.

Ist eine Anwendung hoch optimiert läuft diese auch auf langsamer Hardware akzeptabel schnell, auf einer besseren Hardware wie eine Rakete.

Man kann also mangelnde Performance durch bessere Hardware ausgleichen schleppt sie aber immer mit.

Aber wir schweifen hier gewaltig von der Ausgangsfrage ab und da ist meine Antwort - lohnt nicht bringt nichts.