Hi,
und zwar plagt mich grad folgendes Problem: Ich habe ein dynamisches Array (array of ...), in das ich beim laden meines Programms Daten hineinschreibe. Die Größe lege ich per SetLength fest. Soweit so gut. Nun muss ich aber im Laufe des Programms die Daten wieder ändern, bzw sie werden neu von der Festplatte geladen. Ich habe nun immer gedacht, dass man den Speicher, den das Array belegt, mit SetLength(FooArray, 0) wieder freigeben kann. Dem ist aber nicht so. Also wird der Speicher, den mein Programm belegt, immer größer, was natürlich nicht sehr schön ist. Deshalb die Frage an euch, wie gebe ich den Speicher richtig frei?
Schonmal Danke.

PS:
Ich schreibs mal als Pseudocode, wie ichs bis jetzt gemacht hab:

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

laut Doku nil setzen oder finalize aufrufen, sodass das Betriebssystem den speicher dann freigeben kann, was auch immer das heißen mag ...

Das SetLength müßte eigentlich ausreichen, aber der Delphi Speichermanager gibt den Speicher nicht immer sofort an Windows zurück. Daher kann man nicht von den Werten für das Programm ausgehen. Wenn man wirklich wissen will wieviel Speicher belegt ist muß man sich HeapStatus (oder so ähnlich) ansehen.
Aber für solche Zwecke sind Listen besser.

Wollte ich auch gerade schreiben. Falls das noch aktuell ist:
http://info.borland.com/techpubs/delphi/delphi5/oplg/memory.html
Denn reservier0t Delphi den Speicher von Windows in 1MB chunks und gibt die erst wieder zurueck wenn so ein zusammenhaengender 1MB Block frei wird. Wenn du also dynamische Arrays oft in der Groesse aenderst wird wahrscheinlich der Speicher fragmentiert und deshalb nicht sofort wieder frei gegeben.

@Tokter: Es stimmt schon, dass ich oft die Größe ändere, aber bevor ich die Größe ändere, ruf ich eigentlich immer SetLength 0 auf.
@Pellaeon: Das mit nil hab ich schon ausprobiert, das funtioniert nicht. finalize hab ich noch ned ausprobiert, weil hier schon darüber geredet wurde, ich aber ned ganz mitkomm. Kann mir das vielleicht jmd zusammenfassen?
@Lars: Das mit Listen wär ne Alternative, aber seh ich das als Notnagel, da ich weite Teile meines (ansonsten funktionierenden) Codes ändern müsste.

Gibt es denn vielleicht einen globalen Befehl, der allen Speicher, der in Delphi freigegeben wurde, auch für Windows freigibt?

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

State 1:


State 2: Du vergroesserest dein Array:


Es passt da nicht mehr rein und muss vom Memory Manager wo anders platziert werden. So wird
der Speicher fragmentiert. Da hilft kein SetLength(0), damit gibst du den Speicher nur an den Memory
Manger zurueck und hast ihn wiede zur verfuegung fuer andere Objekte und Arrays (je nach dem wo sie reinpassen).
Haeufig ein dynamisches Array in der Groesse zu aendern ist meist keine gute Idee da es dann staendig im Speicher rumkopiert wird -> langsam.
Wenn du weisst wie gross es maximal werden kann dann leg doch ein Array ueber diese maximale Groesse an und merk dir wieviele gueltige Eintraege es da drin hat. Oder wie schon gesagt, nimm eine Liste...

Tokter hat recht, es is wahrscheinlich Heap-Fragmentation. Allerdings tritt das nur auf, wenn du dein Array sehr oft vergrößerst. Bei sowas wie

ist Heapfragmentation natürlich vorprogrammiert (hoho, habt ihr das Wortspiel gesehen? ). Aber wenn du es nur ein paar mal machst, dürfte es eigentlich kein Prob sein, weil der Speicher für kleinere Objekte, solange sie nicht lokal deklariert sind, nicht verloren geht. Also sowas wie in deinem Beispielprog ist überhaupt kein Prob (666 x 8 Byte + 999 x 8 Byte = 13320 Byte).

Zu Listen würde ich auch nicht unbedingt raten. Das hängt von deinem Anwendungsfall ab. Für mich sah das jetzt so aus, als wären die einzelnen Records eher klein, und da dann 2 x 32 Bit Pointer reinhauhen, würde den Speicherbedarf mal eben verdoppeln. Wenns wirklich viel Kleinkram ist, würde ich es vielleicht auf mehrere Arrays aufteilen, und mir bei Bedarf ein neues Array mit fester Größe dazuholen oder freigeben.
Was willst du denn genau machen?

AL

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

ich packe das immer in eine Klasse bzw. implemetiere es im prog so, dass ich add(array,value) aufrufe, um etwas hinzuzufügen. add sieht dann ungefähr so aus:



noccupied muss irgendwo definiert sein und ist die anzahl belegter stellen im array.
1.72 kommt von irgendeinem Thread in der DP, in dem mal davon die rede war, dass man das array am besten um 172% ergrößern sollte, weil das durchschnittlich der beste Wert sei.

_________________


"User Error. Replace User and hit Continue."

@AL: Ich habe eine Unit, die mir Geometriedaten einer Szene aus verschiedenen Formaten auslesen kann (bis jetzt nur 3ds) und alle möglichen Informationen darüber kapselt. Dazu kommen ein paar Berechnungen, wie Normalen, Tangenten etc. Es handelt also schon um große Datenmengen (zB Figuren mit 2000 Polygonen). Ich will im Laufe des Programms (es ist ein Spiel) diese Modelle mehrmals laden, da die Modelle sich ändern sollen.

Ich habe nun Testweise alles in eine Klasse gepackt, das sieht so aus:



Wenn ich nun die Prozedur \"Freigeben\" aufrufe, tut sich aber immer noch nix am Speicher:

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

wie bereits gesagt: eventuell behält der memory manager den speicher "nur sicherheitshalber" bzw. um ihn für spätere verwendung reserviert zu haben und evtl. überflüsige allocs vermeiden zu können.

Du solltest nur sehen, ob die Speicherbelegung bei mehrmaligen freigeben und neu erzeugen von objekten steigt. Das ist der Knackpunkt.
//Edit: steht ja im ersten post

_________________


"User Error. Replace User and hit Continue."

Also so ne Art Animation mit wahrscheinlich mehr als 15 Modellen die Sekunde...

Naja, Listen kannste da natürlich vergessen. Dann machs entweder so wie Luketheduke es beschrieben hat, oder was Tokter meinte: Du gehst erstmal alle Modelle durch und guckst, wie viele Vertices, Indices, ... das Größte hat (natürlich nach Vertices, TexCoords, Indices, ... getrennt). Und dann richtest du die Arrays nach den Werten ein.

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Also so ne Art Animation mit wahrscheinlich mehr als 15 Modellen die Sekunde...

Nein, es ist so ein Geschicklichkeitsspiel mit Lehrern (für unsere Schule). Eine Runde dauert 90 sekunden. in jeder neuen Runde soll per Zufall ein Lehrermodell aus ner Reihe ausgewählt und geladen werden, der dann 90 sekunden lang angezeigt wird. Gleich alle Modelle zu laden, ist viel zu speicherhungrig.

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Dann musst du halt win32 API benutzen und nicht heap memory manager.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

steig auf C++ um und nimm std::vector

Das sind beides Hinweise die wenig hilfreich sind. Entscheidungen dieser größenordung trifft man bevor man Tasten drückt, nicht wenn schon 80% stehen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com