+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Große Datenmengen, schlechte Performance (/Thread-Grosse-Datenmengen-schlechte-Performance)
Große Datenmengen, schlechte Performance - devilsdoormat - 16.11.2010 18:47
Hallo,
ich weiß, dass dieses Thema prinzipiell auch schon einige male durchgekaut wurde, aber ich habe nichst gefunden, was gut auf mein Problem passt. Da das Programm, um das es sich dreht, inzwischen ziemlich groß ist, würde ich gerne zunächst dadrauf verzichten Bilder oder VIs hochzuladen und erst mal fragen, ob jemandem das Problem prinzipiell bekannt ist:
Ich habe ein Bündel mit Messdateien und in jeder Datei sind Koordinaten von Counts auf 2D-Detektoren abgespeichert. Diese Counts will ich in Arrays abspeichern, welche dann die Detektorbilder darstellen. Dies sind dann 2048x2048 Integer-Arrays. Dafür initialisiere ich ein solches Array mit Nullen, lese alle gesuchten Koordinaten aus allen Datein aus und schreibe sie dann in das Array. Diese Operation muss ich mehrfach wiederholen, da jede Datei an sich wieder in unterschiedliche Messungen unterteilt ist und ich für jede dieser "Untermessungen" einmal durch alle Dateien durchgehe.
Und jetzt das Problem: Anfangs dauert die Operation "Öffne die Datei, hole die Koordinaten, schreibe sie ins Array, öffne die nächste Datei, hole die Koordinaten zur gleihcen Messung usw." ca. eine Minute (die Datenmengen sind schon recht groß). Je häufiger ich das aber wiederhole, desto langsamer wird der Prozess. Unzwar merklich langsamer. Ein Überlegung war, dass mein Speicher oder meine CPU ausgelastet ist. Dies ist aber nicht der Fall. Beide sind weit von ihrer Kapazität entfernt. Starte ich LabView neu und fange an der Stelle an, wo ich aufgehört habe, geht es zunächst wieder schnell. Da würde ich rein gefühlsmäßig sagen, dass doch irgendwelche Ressourcen belegt waren, die durch das Schließen von Labview wieder frei gemacht wurden. Ich habe aber keine Ahnung, wo ich nach dem Knackpunkt suchen soll.
Danke für eure Hilfe
Große Datenmengen, schlechte Performance - Matze - 16.11.2010 21:27
Hallo
' schrieb:Dafür initialisiere ich ein solches Array mit Nullen, lese alle gesuchten Koordinaten aus allen Datein aus und schreibe sie dann in das Array.Was heißt, du schreibst sie dann in das Array? Gehst du den Weg über das VI "Teil-Array ersetzen"? Wenn ja, ist es korrekt und dann kann man ohne weiteres wohl auch nicht sagen, wieso es langsamer wird. Es sei denn, du verzweigst den Array-Draht irgendwo und erzeugst somit Kopien des Arrays.
Was auch Performance kosten kann ist das Verarbeiten großer Arrays in SubVIs. Je nach Art der Programmierung werden hier auch Daten kopiert.
Hast du dir mal das Tool unter "Tools -> Profile -> Leistung und Speicher" angesehen?
Du kannst du leicht erkennen, ob eigene VIs zunehmend Speicher benötigen.
Große Datenmengen, schlechte Performance - macmarvin - 17.11.2010 08:32
' schrieb:...
Ich habe ein Bündel mit Messdateien und in jeder Datei sind Koordinaten von Counts auf 2D-Detektoren abgespeichert. Diese Counts will ich in Arrays abspeichern, welche dann die Detektorbilder darstellen. Dies sind dann 2048x2048 Integer-Arrays.---
Und jetzt das Problem: Anfangs dauert die Operation "Öffne die Datei, hole die Koordinaten, schreibe sie ins Array, öffne die nächste Datei, hole die Koordinaten zur gleihcen Messung usw." ca. eine Minute (die Datenmengen sind schon recht groß). Je häufiger ich das aber wiederhole, desto langsamer wird der Prozess.
...
Wie viele dieser Integer Arrays hast du denn? Fasst du sie in ein 3D zusammen? Wie viele Dateien hälst du denn offen?
Verbrät vielleicht ein Virenscanner auf den Messdaten viel Zeit zum scannen?
Große Datenmengen, schlechte Performance - devilsdoormat - 17.11.2010 10:23
Hallo,
schon mal danke für die Hinweise. Zu euren Nachfragen:
Zitat:Gehst du den Weg über das VI "Teil-Array ersetzen"?Ja
Zitat:Es sei denn, du verzweigst den Array-Draht irgendwoDas Array wird nirgends verzweigt. Es wird nur durch ein Schieberegister durch die Iterationen durchgezogen.
Zitat:Was auch Performance kosten kann ist das Verarbeiten großer Arrays in SubVIs
An genau einer Stelle mache ich das. Ich habe dafür mal drei Bilder angehangen, um das zu verdeutlichen. In "Array_ins-subvi.png" sieht man unter 1, wie ich das Array initialisieren. Die Schleife, an die ich es übergebe ist diejenige, welche durch alle Messdateien durchgeht, wie ich es oben beschrieben habe. Bei 2 wird es an das subvi übergeben. In "subvi.png" wird es als "altes Detektorbild" übernommen. Die Schleife, die das Array dann durchläuft ist noch mal eine Unterteilung der Messdateien in verschiedene Scans, die ich in meinem ersten Post der Einfachheit halber verschwiegen hatte. Jedenfalls werden bei 2 immer die neuen Counts auf das alte Bild addiert. Innerhalb des Subvis, welches die neuen Counts liefert (also links von der Addition) initialisiere ich wieder so ein Detektorbildarray, in welches dann gerade die neuen Coutns über "Teil-Array ersetzen" geschrieben werden, was man in "neue_counts.png" sieht... Ich hoffe ich konnte hiermit so grob erläutern, wie das Programm abläuft.
Und jetzt weiter:
Zitat:Hast du dir mal das Tool unter "Tools -> Profile -> Leistung und Speicher" angesehen?
nein, aber mache ich sofort mal.
Zitat:Wie viele dieser Integer Arrays hast du denn? Fasst du sie in ein 3D zusammen?
Eigentlich maximal 2, wenn LabView sie "am Ende des Kabels" automatisch aus dem Speicher räumt. Aber das weiß ich gerade nicht. Ich habe wie ich oben erläutert habe immer das Array, was alle Counts beinhaltet und kurzfristig das, was die neuen beinhaltet, welche dann auf das erste draufaddiert werden. Ist die Schleife durch alle Messdateien und alle scans durch, schreibe ich das Array in eine Datei und es sollte weg sein, bevor es von vorne los geht.
Zitat:Wie viele Dateien hälst du denn offen?
Das ist eine interessante Frage. Wie lange hält Labview sie denn offen? Ich lese eigentlich immer die Daten einer Datei mit "Read from spreadsheet file" und arbeite dann nur noch mit dem Stringarray, was dabei rauskommt. Muss man explizit sagen, dass LabView die Datei auch wieder schließen soll, oder übernimmt das dieses VI selbstständig? Wenn nicht, könnte es natürlich sein, dass mit steigender Laufzeit ziemlich viele Dateien parallel geöffnet sind
Zitat:Verbrät vielleicht ein Virenscanner auf den Messdaten viel Zeit zum scannen?
Die Dateien werden von nicht gescannt...
So. Langer Text, kurzer Sinn. Ich müsste jetzt auf alle Nachfragen eingegangen sein. Ich klapper jetzt mal die Dinge ab, die ihr mir genannt habt udn melde mich zurück.
Viele Grüße und noch mal vielen Dank
EDIT: Ich sehe gerade, dass man die Namen, die ich den bilder gegeben habe nicht sehen kann. Sie liegen hier aber in der Reihenfolge, in der ich sie angesprochen habe.
Große Datenmengen, schlechte Performance - Matze - 17.11.2010 10:28
Hallo,
im 2. Bild wird meines Wissens bei der Addition der Arrays eine Kopie angelegt. Das kannst du selbst auch prüfen, wenn du das Blockdiagramm offen hast und dann über "Tools -> Profille -> Pufferzuweisungen" (oder sowas) gehst (Option "Arrays" muss aktiviert sein). Dann blinken kleine schwarze Quadrate an den Stellen auf, an denen Speicher zugewiesen wird.
Da du Arrays addierst, wird mit ziemlicher Sicherheit Speicher für das neue Array reserviert. Bei großen Arrays natürlich enttsprechend viel.
Große Datenmengen, schlechte Performance - devilsdoormat - 17.11.2010 10:41
Hi,
Zitat:Dann blinken kleine schwarze Quadrate an den Stellen auf, an denen Speicher zugewiesen wird.
hmm.. also bei mir blinkt es quasi an allen Biedienelementen oder Ausgängen von irgendwelchen VIs, aber nicht an dem Additionszeichen. Auch hier noch mal ein Bild
Große Datenmengen, schlechte Performance - Matze - 17.11.2010 10:49
Schade, dass der LabVIEW-Compiler das nicht erkennt und optimiert. Gerade die Kopie am Eingang des SubVIs ist im Prinzip nicht nötig.
Und mit LabVIEW 2009 gibt es wohl keine Möglichkeit, das zu verhindern. Mit LV 2010 geht es, dort lassen sich SubVIs inline einfügen und somit werden diese vorm Kompilieren durch das eigene Blockdiagramm ersetzt. Aber gut, das hilft dir natürlich nichts.
Es gibt jedoch VIs, um mit Datenreferenzen zu arbeiten. Da müsstest du dann außerhelb des SubVIs eine Referenz auf das Array erstellen, im SubVI mit der Referenz arbeiten und nach dem SubVI-Aufruf (außerhalb) wieder schließen.
Wie man mit Datenreferenzen arbeitet, wird hier gezeigt.
Einen versuch ist es Wert und der Aufwand müsste sich in Grenzen halten. Zur Sicherheit würde ich das aktuelle Projekt an deiner Stelle vor den Änderungen jedoch sichern, um es ggf. wiederherstellen zu können.
Große Datenmengen, schlechte Performance - devilsdoormat - 17.11.2010 13:32
Hi,
ich habe das jetzt mit der Referenzierung genauso gelöst und es ist leider nicht besser geworden. Wie man in dem Bild, was ich angehangen habe erkennt, wird laut Pufferzuweisung zwar kein speicher zugewiesen, wenn ich die referenz übergebe, aber sobald die Referenz in der Inplace-Elementstruktur in ein Array umgewandelt wird...
ich will jetzt als nächstes mit dem "Leistung und Speicher"-Tool noch mal genau verfolgen, welches subvi immer langsamer wird. Ich berichte dann noch mal
Große Datenmengen, schlechte Performance - macmarvin - 17.11.2010 15:47
' schrieb:Schade, dass der LabVIEW-Compiler das nicht erkennt und optimiert. Gerade die Kopie am Eingang des SubVIs ist im Prinzip nicht nötig.
Und mit LabVIEW 2009 gibt es wohl keine Möglichkeit, das zu verhindern. Mit LV 2010 geht es, dort lassen sich SubVIs inline einfügen und somit werden diese vorm Kompilieren durch das eigene Blockdiagramm ersetzt. Aber gut, das hilft dir natürlich nichts.
Die Optimierung hängt vom umliegenden VI ab, so pauschal kannst du es nicht sagen, daß der Compiler da nix erkennt!
Die Puffer an den Eingängen sind normal. Schließlich wird da das aktuelle VI betrachtet und nicht das VI im Kontext.
[attachment=30682]
Die grünen Puffer sind absolut normal. Am SubVI sieht man an den Ausgängen Puffer, die wären zu hinterfragen. Schön zu sehen, daß z.b. bei den Eingängen dieses SubVIs keine Puffer angelegt werden, wenn man aber dieses SubVI selbst öffnet und sich die Puffer anschaut, wird man dort welche sehen. In diesem VI würde ich die Optimierung ansetzen und schauen wie der Puffer am Ausgang des eigentlich durchgereicht Stringarrays weg bekommen könnte.
Die Addition braucht keinen eigenen Puffer, da der obere Eingang höchstwahrscheinlich derjenige ist der weiter verwendet werden kann und am unteren Eingang eh gerade am SubVI Ausgang eine Kopie liegt.