Laden...

byte[]-Array aus dem Speicher löschen

Erstellt von CaptainIglo vor 17 Jahren Letzter Beitrag vor 17 Jahren 2.438 Views
C
CaptainIglo Themenstarter:in
366 Beiträge seit 2005
vor 17 Jahren
byte[]-Array aus dem Speicher löschen

Hi,

ich habe ein byte[]-Array, welches sehr groß ist (3-10MB) und mehrmals neu (mit etwas anderer Größe) instanziert wird, aber der benötigte Speicher, von der alten Instanzierung wird nicht freigegeben.
Wenn ich vor der neuen Instanzierung ein "byte[]" = null und GC.Collect() aufrufe, wird der Speicher freigegeben, aber ich habe gelesen, man sollte GC.Collect() möglichst nicht einsetzen.
Was gibt es noch für Möglichkeiten den Speicher freizugeben?

mfg
CaptainIglo

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo CaptainIglo,

Was gibt es noch für Möglichkeiten den Speicher freizugeben?

die beste Möglichkeit ist nichts tun. Der Speicher wird automatisch freigegeben, wenn er nicht mehr benötigt wird (bzw. wenn er wieder benötigt wird 🙂

herbivore

C
CaptainIglo Themenstarter:in
366 Beiträge seit 2005
vor 17 Jahren

Naja, aber mein Programm schaufelt sich schön langsam immer mehr RAM zu, obwohl es ihn nicht braucht.
Brauchen tut es ~20MB, wenn ich es aber ~1h ohne das GC.Collect() laufen lasse, hat es lt. TaskManager ~100MB...

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo CaptainIglo,

hm, wozu hast du denn die lustigen, vielen Speicherriegel in deinem Rechner stecken? Sie zu benutzen kostet doch nichts. Wenn der Speicher anderweitig gebraucht wird, wird er ja freigegeben. Außerdem was sind schon 100MB?

herbivore

915 Beiträge seit 2006
vor 17 Jahren

Also gegen GC.Collect spricht eigentlich nichts, kümmere mich in etlichen Anwendungen auch selbst darum dass nach Formularen oder Businessobjekten der Garbage Collector manuell angestoßen wird.

Wie vernichtet stand Andreas unter den flammenden Augen seiner Kunden.
Ihm war's, als stünde des Schicksals dunkle Wetterwolke über seinem Haupte X(

C
CaptainIglo Themenstarter:in
366 Beiträge seit 2005
vor 17 Jahren

Es sieht für den nichtsahnenden User eben nicht schön aus, wenn ein kleines Programm, was "fast nix" tut >100MB RAM verbraucht...

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo CaptainIglo,

der "nichtsahnenden User" wird gar nicht erst sehen, dass es >100MB RAM verbraucht.

herbivore

C
CaptainIglo Themenstarter:in
366 Beiträge seit 2005
vor 17 Jahren

Mit "nichtsahnender User" meine ich keine DAU's sondern, solche wo den Ramverbrauch beobachten, aber nicht wissen, das die 100MB freigegeben werden, wenn sie benötigt werden und mit der "Auslagerungslust" von Windows ist das sicher auch nicht gut gepaart...

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo CaptainIglo,

also du kannst das gerne machen, wie du willst und Andreas.May sagt, wird nicht gleich der Rechner explodieren, wenn du GC.Collect benutzt. Aber wenn du mich fragst, bleibe ich dabei.

Sicher kann man immer eine bestimmte Benutzerruppe konstruieren. Also welche die zwar A wissen/können, aber B nicht. Fragt sich bloß, wie groß die dann jeweils ist. Außerdem wird der Ramverbrauch-Beobachter-aber-nicht-mehr-Wissende schon bei 20MB für ein Programm, dass "fast nix" tut abkotzen und der Brechreiz wird bei 100MB vermutlich nur unwesentlich größer sein. 🙂

herbivore

915 Beiträge seit 2006
vor 17 Jahren

Na ja, 100MB ist schon recht viel - evtl. musst deinen Berechnungsalgorithmus noch mal überdenken.

Bin zwar kein Student aber zum Beispiel wäre ne gute UNI Idiotenaufgabe zählt mal von 1 bis 1000 Millionen alle zahlen zusammen. Während etliche wohl ne schleife durchlaufen lassen, nutzen manche die Gaußsche Formel und lösen das Problem Performant. Meistens (nicht immer) lässt sich durch Mathematik etliches an Problemen lösen.

Wenn wirklich keine andere Wahl hast, nutz einfach den Garbage Collector - Es spricht wirklich nichts dagegen.

Wie vernichtet stand Andreas unter den flammenden Augen seiner Kunden.
Ihm war's, als stünde des Schicksals dunkle Wetterwolke über seinem Haupte X(

C
CaptainIglo Themenstarter:in
366 Beiträge seit 2005
vor 17 Jahren

Dann bleib ich eim GC.

@anderer Algorithums:
Hier nicht möglich, da ich die Daten in dieser Form in einem byte[] benötige, um sie weiterzuverarbeiten.
Um genau zu sein, sind es Musikdateien welche "gestreamt" werden, d.h. die Netzwerkklasse schreibt die erhaltenen Daten in das byte[] und die Soundklasse beginnt daweil schon das byte[] abzuspielen...

0
767 Beiträge seit 2005
vor 17 Jahren

also ich bin der meinung dass man den GC nur anstossen sollte wenns wirklich nötig ist. .net macht das aus gutem grund "wenn es das für richtig hält". wenn du den gc wegen jeder kleinigkeit anstösst wird der "nichtsahnende user" zwar sehn dass das programm weniger speicher belegt, aber er wird auch sehn dass prozessorzeit höher ist - was ich bei programmen "die eh nichts tun" kritischer finde als den speicherverbrauch...

loop:
btst #6,$bfe001
bne.s loop
rts

B
1.529 Beiträge seit 2006
vor 17 Jahren

Wenn dich der Speicherverbrauch so stört, warum nutzt du dann nicht das gleiche Array mehrmals?

C
CaptainIglo Themenstarter:in
366 Beiträge seit 2005
vor 17 Jahren

Original von Borg
Wenn dich der Speicherverbrauch so stört, warum nutzt du dann nicht das gleiche Array mehrmals?

Tu ich ja, aber ich initialisiere es jedesmal neu, da ich immer eine etwas andere Größe brauche...

B
1.529 Beiträge seit 2006
vor 17 Jahren

Ja, und bei jedem neu initialisieren wird halt ein neues Array angelegt...
Leg doch einfach ein Array mit einer bestimmten Größe an und speicher in einem zusätzlichen int, wieviel Elemente du momentan nutzt. Dann brauchst du nur dann ein neues erzeugen, wenn das alte zu klein ist.

T
21 Beiträge seit 2006
vor 17 Jahren

Original von Borg
Leg doch einfach ein Array mit einer bestimmten Größe an und speicher in einem zusätzlichen int, wieviel Elemente du momentan nutzt. Dann brauchst du nur dann ein neues erzeugen, wenn das alte zu klein ist.

Ja, das mache ich auch, wenn es geht: einen globalen Puffer (ob statisch oder für jedes Objekt kommt drauf an) anlegen, den ich nur ab und zu vergrößere, aber ansonsten für alle Schreib/Lesevorgänge benutze.

TeDe