+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: ActiveX & .Net (/Forum-ActiveX-Net)
+---- Thema: Speicher läuft hoch (/Thread-Speicher-laeuft-hoch)
Speicher läuft hoch - Nina - 28.09.2007 09:09
Hallo,
im folgenden versuche mein Problem einmal verständlich darzustellen.
Ich habe ein Prüfprogramm für Kameras zu entwickeln (Firewire und GigE). Die Schnittstelle zu den Kameras in .NET realisiert. Die Bilder werden über eine Callback gemeldet. Wenn ein Bild dargestellt werden soll, wird ein Bitmap-Objekt erzeugt und der Picture-Box zugewiesen. Scheinbar werden nicht mehr benötigte Objekte nicht aus dem Speicher gelöscht und auch "Speicherfreigabe anfordern" scheint nicht zu funktionieren. (Normalerweise braucht man sich bei .NET ja darum nicht zu kümmern)
Zur Lösung der Problems habe ich nun versucht nur ein Bitmap-Objekt anzulegen und mit Hilfe eines .NET-Programmes mit den aktuellen Bilddaten zu bearbeiten. Dieses aktualisierte Bitmap wird der Picture-Box zugewiesen. Nach einer Zeit stürzt die Bildausgabe mit der Ausschrift
"Die Bitmap ist bereits gesperrt" ab.
Fragen:
Wie kann ich nicht mehr verwendeter Speicher freigegeben werden?
Oder auf welche Weise kann ein Absturz der Bildausgabe verhindert werden?
Bin über jede Hilfe dankbar.
Viele Grüße Nina
Speicher läuft hoch - Y-P - 28.09.2007 09:30
Das mit dem Speicher kannst Du so wie im Anhang machen, habe ich aber so noch nie verwendet...., also einfach mal probieren.....
Gruß Markus
Speicher läuft hoch - Nina - 28.09.2007 10:06
Hallo Markus,
vielen Dank für Deine Antwort, aber das habe ich schon probiert aber es hat nicht wirklich funktioniert.
Viele Grüße
Nina
Speicher läuft hoch - rolfk - 29.09.2007 19:07
' schrieb:Das mit dem Speicher kannst Du so wie im Anhang machen, habe ich aber so noch nie verwendet...., also einfach mal probieren.....
Gruß Markus
Das funktioniert nur für Speicherblöcke die LabVIEW in VIs anlegt und beibehält um sie bei einer folgenden Ausführung dieses VIs wieder zu verwenden, statt sie gleich fortzuwerfen (was Zeit kostet) und sie danach wieder neu anfragen zu müssen, (was noch mehr Zeit braucht). Damit ist auch schon deutlich dass Request Memory Deallocation in den meisten Fällen nur eines tut, nämlich die Ausführungszeit eines LabVIEW Programmes zu verlangsamen!
Die Bereiche wo das eventuel sinnvoll ist, sind sehr eingeschränkt, etwa wenn ein VI nur einmal ausgeführt wird aber dabei eine riesige Array in einem Schieberegister (das man auch programmtechnisch selber leeren kann in der letzten Iteration) oder in einem Frontpanelkontrol zurücklässt. Ansonsten Finger weg von dieser Funktion!
Memory das von externem Code gemanaged wird (.Net, ActiveX, DLLs, Treiber etc.) kann LabVIEW sowieso auf keine einzige Weise ans System zurückgeben. Dass muss schon die Entität tun die es angefordert hat. Auch auf ein Memory Leak in LabVIEW selber, also ein echtes Leak wo LabVIEW aus irgendeinem Grund die Referenz zum Speicher verloren hat bevor es ans System zurückgegeben wurde, kann durch diese Funktion NICHT freigegeben werden. Dazu müsste LabVIEW einen komplett andere interne Speicherverwaltung haben mit einer mehr oder weniger komplizierten Garbage Collection. Aber Memory Leaks in LabVIEW selber sind wirklich extrem selten.
Und nein bei .Net braucht man sich nicht einfach nicht mehr um Speicher zu kümmern. Das stimmt vielleicht innerhalb eines C# Programms noch einigermassen, solange man nur managed Interfaces verwendet aber spätestens beim Übergang zu anderen Systemen (also auch im Zusammenhang mit LabVIEW oder Aufruf von unmanaged Interfaces wie WinAPI DLLs) kann .Net nicht jedesmal magisch wissen wann LabVIEW einen Datenbuffer nicht mehr nötig hat und LabVIEW kann auch nicht immer wissen ob eine .Net Komponente diesen Buffer noch weiter verwenden will. Der erwähnte Bildbuffer ist ein guter Kandidat für so ein Problem.
Rolf Kalbermatter