Alternative zu geschachtelter for-Schleife

Hallo zusammen,

zuerst einmal Danke an alle, die in diesem Forum fleißig die Fragen anderer beantworten. Mir hat das bisher schon sehr viel geholfen.

Nun zu meiner Frage:
In meiner Simulationsumgebung laufen alle Werte in einer funktionalen globalen Variable zusammen, die aus einem einzigen Cluster besteht.
Alle anderen VIs greifen auf diese FGV zu, darunter auch eine Art "Recorder" der die Werte zyklisch ausliest und in eine .csv-Datei speichert.
Allerdings schafft es der Recorder nicht, den vorgegeben Sollzyklus einzuhalten.
Bisher dachte ich, dass der Grund hierfür die Datei-IO-Operationen sind, es stellte sich aber heraus, dass das Problem ein Sub-VI des Recorders ist.

Dieses Sub-VI läuft über alle Werte der FGV und überführt diese in ein String-Array, dass dann in die .csv-Datei geschrieben wird.
Dabei liegt innerhalb der for-Schleife eine weitere for-Schleife, für den Fall, dass im Cluster der FGV weitere Cluster vorhanden sind.
Und ich denke hier liegt der Ursprung für die schlechte Performanz dieses VIs.

Gibt es zu dieser Struktur alternativen, die die Laufzeit des VIs verbessern?
Anbei noch ein Screenshot, zum hoffentlich besseren Verständnis.

Vielen Dank schon mal

Anzeige

Hallo koan,

so richtig ist mir nicht klar, warum du diesen Aufwand im subVI betreiben musst!

Ich verwende als Datenspeicher sehr gern Variant-Attribute, google doch einfach mal nach "LabVIEW red black tree"! Der erste Treffer sollte irgendwas mit "Darrens Nugget" sein, den dann aufmerksam lesen…

Der Performance-Killer ist der Zugriff auf die Daten über die Eigenschaftsknoten. Dazu ist nämlich ein Threadwechsel verbunden.
Versuch doch das VI Datenflußkonform zu programmieren.

Gruß Holger

@Gerd: Vielen Dank für den Hinweis, das mit den Variant-Attributen werde ich mal probieren.

@Holger: Den Eigenschaftsknoten brauche ich doch aber, um über das FGV-Cluster zu iterieren, oder gibt es hierzu noch eine andere Möglichkeit?

Zur Perfomance kann ich nichts sagen. Nur: Deine Vermutung, dass mehrfach geschachtelte Strukturen grundsätzlich Perfomance-Killer sind, teile ich nicht.
Das Problem ist ja auch, dass komplexe Elemente wie z.B. Cluster, Registerkarten weitere komplexe Elemente enthalten können, und diese wieder. Einzelelemente können also beliebig tief verschachtelt sein.
Ich habe mal ein Sub-VI gemacht, welches die Referenzen, Beschriftungen und KlassenID aller Elemente anzeigt, wie tief sie auch verschachtelt sein mögen. Ich brauchte das für Sprachanpassungen, oder für Schriftgößenänderung aller Elemente.
Wenn Du dein VI so umstellt, würdest Du ganz innen eine Struktur (für die Verschachtelungstiefe 1, weiter geht es bei Dir dann nicht) einsparen. Ganz außen käme allerdings eine While-Schleife hinzu.

Hier ist es. Von einem beliebigen VI (natürlich möglichst groß und komplex) aufrufen und staunen... (man muß noch den "RefCluster" von seiner Typdefinition, die ich hier nicht mitliefere, trennen, damit es läuft. Man kann das VI auch leicht auf Pfad-Input statt Ref-Input ändern. Dann muß das zu analysiende VI gar nicht im Memory sein.)

  ElementRefs.vi (Größe: 16,1 KB / Downloads: 211)

Edit:

  ElementRefs2013.vi (Größe: 16,23 KB / Downloads: 210)

Hallo koan,

ja, die Propertynode brauchst du in deinem VI.
Was machst du eigentlich, wenn der "innere" Cluster in der zweiten Ebene ebenfalls wieder Cluster enthält?

Anzeige

@Lucki: leider kann ich dein VI nicht öffnen, da es eine neuere LV Version verwendet als meine.

@Gerd: Dieses Problem ist mir auch schon aufgefallen, da das VI derzeit aber nur in einer kleinen Abteilung verwendet werden soll, habe ich in der Beschreibung angegeben, dass das eingehende Cluster weitere Cluster nur auf der ersten Ebene enthalten darf

Wenn die Daten aus der FGV als Custer kommen, ist die Struktur fest und kann explizit ausprogrammiert werden.

Holger

@Holger: ach so meinst du das. Vll sollte ich hier noch erwähnen, dass das VI bewusst so gehalten ist, dass man möglichst wenig manuell ändern muss wenn es in anderen Zusammenhängen eingesetzt wird.

Nach mal zurück zur Ausgangsfrage: Gibt es Alternativen, um die Laufzeit zu verbesseren?
Die Perfomance-Killer sind ja, wie schon festgestellt, die vielen Eigenschaftsknoten. Zu denen gibt es hier aber keine Alternative. Und deshalb wird man mit der Perfomance, so wie sie ist, im Wesentlichen leben müssen. Das VI, welches ich gepostet habe, ist da auch nicht besser. Um von 300 Elementen in einem VI alle interessierenden Werte zu ermitteln, kann schon mal eine Sekunde vergehen.