Ich habe allgemein von globalen Variablen gesprochen, nicht was man diesen zuweist.Alfons Mittelmeyer hat geschrieben:Du vermischt da einige Konzepte. Statische globale Variablen werden im '.data' - Segment abgelegt. Bei dynamisch allokiertem Speicher werden nur die Pointer also die Verweise auf den Speicher im '.data' Segment abgelegt. Und der Speicher wird dann aus dem Heap allokiert, etwa:
Ich denke du weißt nicht was das `static` Keyword in C bedeutet, besonders im Zusammenhang mit globalen Variablen.Alfons Mittelmeyer hat geschrieben:Wie wir gesehen hatten, haben globale Pointer mit dynamisch allokiertem Speicher sehr wohl etwas mit Speicherverwaltung zu tun. Bei statischen Variablen bleibt allerdings der Speicher stets gleich und muss man sich nicht darum kümmern. Der Vorteil der Speicherverwaltung von Python ist, dass man sich normalerweise durch das in der Zuweisung und der pop-Funktion bereits enthaltene del, so ziemlich gar nicht um die Speicherverwaltung zu kümmern braucht. Stimmt natürlich nicht ganz, denn wer Daten in Listen und dergleichen speichert, da immer mehr hineinmüllt und sich nicht darum kümmert, dass etwas nur kurzzeitig gebraucht wurde, und glaubt, dass die Speicherverwaltung automatisch seinen Saustall aufräumt, der liegt verkehrt.
Natürlich kann man Referenzen auf jedes Objekt in einer Liste speichern, aber wer macht das schon .. du behälst ganz automatisch nur die Referenzen die du später noch brauchst, del ist da überflüssig.
Ein GC basiert nicht (zwingend) auf Reference Counts. Zu dem Problem das du beschreiben willst, du programmierst schlecht wenn du Referenzen auf unbenutzte Objekte behälst. Deine "destroy" oder sonstwas Funktion bringt dir auch nichts, wenn noch ein anderes Objekt eine Referenz behält, also schwachsinn.Alfons Mittelmeyer hat geschrieben:Daraus besonders dieser Teil:Ob der Speicher noch benutzt werden soll, weiss der gc nicht. Er weiss nur ob der Referenzzähler Null ist oder nicht - bzw. ob die Referenz noch beinen reservierten Speicherbereich zeigt. Also, ob etwas noch gebraucht wird, weiß der gc nicht und wenn jemand Objekte, die er nicht mehr braucht, nicht aufräumen will sondern einfach weiter ansammelt, dann wird eben der Speicher vollgemüllt, bis Python bedendet wird oder bis es einen Crash gibt. Und bei lang laufenden Programmen mit großen Datenbeständen, kommt es eben dann zu Crashs.der GC kümmert sich darum dass Speicher wieder freigegeben wird sobald er nicht mehr benutzt wird[/b] (vereinfacht: er scannt den Speicherbereich nach Referenzen/Pointern, wenn er etwas findet dass in einen reservierten Bereich zeigt, wird der Speicher noch gebraucht und nicht freigegeben).
Weil `del` bei Dictionaries "magisch" ist und bedeutet, "entferne diesen Key aus dem Dictionary".Alfons Mittelmeyer hat geschrieben:Während lokale Variablen in Funktionen selber wieder beseitigt werden, werden globale Variablen nicht von selber aufgeräumt, sondern die Daten bleiben erhalten, bis man sie löscht. Warum man bei Einträgen in Listen und Directories dazu del nehmen darf, bei einzelnen Variablen dagegen nicht, bleibt ein Rätsel.
Nach beendigung eines Scripts/Programms wird der Speicher vom Betriebssystem sowieso wieder freigegeben. Was du als "Skript" bezeichnest ist eine Krankheit, ein Missbrauch des Modulsystems von Python, der eine oder andere Python Enthusiast wird sich bei solch einem Code im Grab umdrehen.Alfons Mittelmeyer hat geschrieben:Ich brauche kein low memory profile aber ein grow and grow and grow memory profile ebensowenig. Und Python ist optimal geeignet, hervorragend. Ein guter Garbage Collector kann keinen Saustall aufräumen, weil jemand den Speicher vollmüllt. Ein manuelles Memory Management brauche ich nicht. Denn ich habe die destroy() Funktion geschrieben, die den Speicher leer räumt. Und wer überhaupt keine Ahnung hat, bist Du. Sonst hättest Du gemerkt, dass ich darüber gar nicht mehr dikutieren brauche, weil ich die Funktion habe, die automatisch nach Ablaufen eines Scripts, den vom Script verwendeten Speicher wieder löscht. Und um Module ging es auch nicht, sondern um Scripts.
