Speicherbedarf FGV

Hallo!

Ich möchte anhand einer funktionalen globalen Variable eine Audioaufnahme zwischen verschiedenen VIs austauschen.
Prinzipiell funktioniert das ganze auch schon, jedoch wundere ich mich über den hohen Speicherverbrauch.

Die Daten liegen als u16 Werte mit einer Abtastrate von 44100 kHz auf der Festplatte gepuffert vor. Angenommen, ich möchte die letzten 10 Sekunden dieses Puffers auslesen. Somit komme ich auf ein Datenaufkommen von 44100 S/s x 10 s x 2 Byte/S = 882000 Byte. Schiebe ich dieses Array aus 441000 Werten in die FGV, so benötigt diese laut dem "Profile Performance and Memory"-Tool 3533,86 kByte. Das ist ungefähr das vierfache Datenaufkommen.

Kann mir jemand einen Tipp geben, wo dieser Overhead herkommt, bzw. wie ich ihn minimieren bzw. eliminieren kann?

Gruß,
Christian

Anzeige

Hallo Christian,

dazu müsste man deine FGV sehen.

Erster Check:
- Schieberegister braucht Speicher
- Anzeige (=Daten-Ausgang der FGV) braucht Speicher
- alle Datenbuffer korrekt typisiert (als U16)?
- lass dir die Bufferallocations anzeigen...

Hallo Gerd,

vielen Dank für die schnelle Antwort.
Im Anhang befindet sich meine FGV.

In der LV-KnowledgeBase habe ich jedoch gelesen, dass LabVIEW KEINEN neuen speicherbereich anlegt, wenn die Daten NICHT verändert werden... Das ist in meinem Beispiel meiner Meinung nach der Fall. Deine Aussage bezüglich der allozierung von Speicher für Schieberegister, Ausgänge etc. leuchtet mir zwar ein - würde aber doch der o.g. Auffassung wiedersprechen?!

Hättest du eine andere Idee um das Datenaufkommen zu minimieren?
P.S.: Das Beispiel war mit 10 sekunden gewählt, da der Puffer aber beliebige Größe haben kann, müssen auch weitaus größere Datenmengen gehandelt werden können (beispielsweise 10 minuten = 600 sekunden)

Hallo Christian,

ich würde den Read-Case so machen:
   
Da wird mir nur eine Bufferallocation für das Schieberegister angezeigt!

Zitat:eine andere Idee

Queues bieten sich immer an, wenn nur ein Consumer bedient werden soll...

Da in der Tat nur ein Consumer bedient wird, könnte eine Queue tatsächlich in Frage kommen.
Diesen Ansatz hatte ich bereits auch schonmal in Betracht gezogen, war mir jedoch nicht sicher, ob dieser tatsächlich Speicher einsparen wird. Aber mit den nun gewonnenen Kentnissen, sollte damit wirklich das Aufkommen minimiert werden können.

Ich werde das mit der Queue dann mal näher erörtern!
Danke!

Dein Read-Case ist in der Tat suboptimal. LabVIEW ist eine byValue sprache und jeder Drahtabzweig bedeutet eine Datenkopie. Sowie GerdW den Readfall geändert hat, sollte diese unnötige Speicherallozierung behoben sein.

Anzeige

(10.01.2012 15:19 )abrissbirne schrieb:  Dein Read-Case ist in der Tat suboptimal. LabVIEW ist eine byValue sprache und jeder Drahtabzweig bedeutet eine Datenkopie. Sowie GerdW den Readfall geändert hat, sollte diese unnötige Speicherallozierung behoben sein.

Nein!

Sich die Buffers nur in der FGV selbst anzuschauen reicht meist nicht aus. Auf jeden Fall das Ganze nochmals im Kontext, also in den eigentlichen ZielVIs checken.
Der Buffer aus dem Schieberegister _muss_ nach dem Aufruf der FGV für das/die ZielVIs kopiert worden sein, da LV nicht sicherstellen kann, daß die Daten in der FGV nicht parallel geändert werden. Vom Gesamtspeicherverbrauch geben sich die beiden Versionen deshalb auch nichts. Da könnte mach sogar eher noch zur bedingten Kopierversion argumentieren, wenn es in Zukunft noch Cmds in der FGV gibt, die nicht den gesamten Puffer zurückgeben müssen.
   

(12.01.2012 10:04 )macmarvin schrieb:  

(10.01.2012 15:19 )abrissbirne schrieb:  Dein Read-Case ist in der Tat suboptimal. LabVIEW ist eine byValue sprache und jeder Drahtabzweig bedeutet eine Datenkopie. Sowie GerdW den Readfall geändert hat, sollte diese unnötige Speicherallozierung behoben sein.

Nein!

Doch! (zumindest in der fgv!)

(12.01.2012 10:44 )abrissbirne schrieb:  Doch! (zumindest in der fgv!)

Wenn Du Recht hättest, wäre der Speicherverbrauch der ersten Version größer als bei der Zweiten. Mit dem angehängten Snippet und dem Taskmanager/ProcessExplorer/LV Perfomance&Memory lässt sich das recht einfach testen.

(12.01.2012 11:36 )macmarvin schrieb:  

(12.01.2012 10:44 )abrissbirne schrieb:  Doch! (zumindest in der fgv!)

Wenn Du Recht hättest, wäre der Speicherverbrauch der ersten Version größer als bei der Zweiten. Mit dem angehängten Snippet und dem Taskmanager/ProcessExplorer/LV Perfomance&Memory lässt sich das recht einfach testen.

Natürlich darf das FP nicht geöffnet sein und es gibt einen Unterschied zw. LV 2011 und der hochgeladenen LV 8.6. Da ist der Compiler noch nicht so schlau wie heute.