Programmbearbeitung durch globale Variablen erheblich langsamer?

Hallo zusammen

ich habe eine Frage zu der Speicherauslastung von globalen Variablen. Ich habe gelesen, dass man auf globale Variablen lieber verzichten sollte. Liegt das nur daran, dass sie gegen das Datenflussprinzip verstoßen und zeitlich nicht zu synchronisieren sind oder gibt es noch andere Probleme? Verlangsamen sie zB den ganzen Kompilierungsprozess?

Derzeit ist unser Programm sehr komplex, wir achten aber darauf, viele SubVIs zu verwenden. Nur 2 SubVIs übersteigen eine Größe von 700 kB (ca. 800 kB). Zudem verwenden wir unzählige globale Variablen. Wenn man nun kleine Änderungen in dem übergeordneten Vi vornimmt, dauert es ca. eine Viertelstunde bis Labview wieder ansprechbar ist, obwohl keine Änderungen an den darunterliegenden SubVis oder globalen Variablen gemacht wurden. Da sollte Labview doch keine neue Kompilierung der SubVIs machen, oder? Warum dauert es so lange, bis Labview ein übergeordnetes Vi öffnet oder speichert? Je höher die Ebene, desto länger dauert das Abspeichern bzw das Öffnen.

Ich bin dankbar für jeden Tipp wie das Programm/ das Projekt wieder schneller bearbeitet werden kann.

Schöne Grüße

Anzeige

Hallo,

ich wuerde dir empfehlen das hier anzusehen:
Improving the Performance of Your LabVIEW Applications - Part 1

und Teil 2

Es zieht sich zwar etwas, aber hier wird z.B. erklaert wie die Sub-VI's kompiliert werden ~min 40
Es hat mir sehr geholfen effizienter zu Programmieren, vielleicht nuetzt es dir ja auch.

Da gab es gerade ein Diskussion, gewissermassen off-toppic hier.

Zitat:Ich habe gelesen, dass man auf globale Variablen lieber verzichten sollte

Wo? Wenn die Quelle von NI ist und neueren Datums ist, würde ich das ernstnehmen, bitte nenne mir dann die Quelle. Oder war das nur ein Gelaber in irgendeinem Forum?

Du hast doch hoffentlich eines richtig gemacht:
Es gibt zum globalen Datenaustausch - d.h. zum Datenaustausch zwischen verschiedenen VIs ohne die Benutzung von Drahtverbindungen - nicht nur GVs und FGVs. Es gibt außerdem Queues und Melder.

Das Dümmste, was man machen kann, ist, FGVs und GV an einer Stelle zu verwenden, an denen Queues oder Melder die 1000fach bessere Alternative wären. Da ich nichts über Deinen LV-Level weiß, will ich das jetzt nicht näher ausführen, ich gehe eher davon aus Du weißt da Bescheid.

Danke für die Antworten,

meine Frage die sich mir jetzt stellt, ist, ob FGVs nun mehr oder weniger Speicherauslastung oder Kompilierungsaufwand gegenüber Globalen Variablen für LabView bedeuten.

Danke im Vorraus.

(06.06.2012 14:57 )Ativon schrieb:  Danke für die Antworten,

meine Frage die sich mir jetzt stellt, ist, ob FGVs nun mehr oder weniger Speicherauslastung oder Kompilierungsaufwand gegenüber Globalen Variablen für LabView bedeuten.

Danke im Vorraus.

Das lässt sich nicht generel sagen. Grundsätzlich sind globale Variablen aus zwei Gründen gefährlich.

1) Race Conditions

Wenn Du eine globale Variable an mehreren Stellen liest und schreibst dann hast Du die Chance auf Race Conditions. Stell Dir mal vor dass Du an Stelle X in Deinem Code die Globale jeweils um eins vergrösserst und an Stelle Y jeweils um eins verkleinerst. Dazu musst Du die Globale jeweils lesen und dann manipulieren und wieder zurückschreiben. Wenn die Codeteile X und Y grundsätzlich parallel ablaufen können, was in LabVIEW automatisch gegeben ist wenn zwischen diesen Teilen keine Datenabhängigkeiten bestehen, hast Du eine potentielle Race Condition, da in der Zeit dass Du die Globale liest und wieder zurückschreibst eine jeweilige Änderung dieser Globalen aus dem oder den anderen Codeteilen einfach überschrieben wird.

Mit FGVs lässt sich das besser managen, da man in ihnen eine explizite Methode Increment und Decrement implementieren kann, die dann von Deinem Code aufgerufen werden können. Da eine FGV aus naheliegenden Gründen NICHT reentrant sein kann, ist damit auch automatisch gewährleistet dass die Variable die darin abgespeichert ist nicht einfach durch einen zweiten parallelen Aufrufe der FGV unbootmässig beeinflusst wird, denn LabVIEW serialisiert SubVI Aufrufe auf nicht reentrante VIs automatisch.

2) Speicherverbrauch

JEDES Lesen und Schreiben kopiert den vollen Inhalt der Variablen. Das ist kein Problem bei Skalaren oder kleinen Arrays, aber geht sowohl in Speicherverbrauch als auch CPU Zeit doch in die Zahlen wenn Du das auf grosse Datenarrays anwendest.

Nimm auch hier voriges Beispiel einer Veränderung der abgespeicherten Daten mit anschliessendem Zurückschreiben. Wenn es sich hier um ein grosses Array handelt, hast Du durch die doppelte Kopie der Daten sowohl beim Lesen als auch Schreiben jeweils eine ziemliche Speicherauslastung als auch CPU Zeit. Diese grössere CPU Zeit vergrössert zudem das Zeitfenster in dem ein paralleler Zugriff auf die Daten eine Race Condition verursachen kann.

Wenn Du für die Manipulation der Daten eine Methode in der FGV machst die diese Manipulation innerhalb der FGV vornimmt, hast Du je nach Operation der gewünschen Manipulation die Chance, dass zumindest eine der zwei Datenkopien ganz entfällt und bei Operationen die LabVIEW sogenannt Inplace machen kann, entfällt gar jegliches Datenkopieren.

Grundsätzlich ist zu sagen dass eine FGV die NUR eine Get und Set Methode enthält genauso schrecklich ist wie eine Globale, mit denselben Nachteilen und Problemen. Eine FGV wird dann aber interessant wenn Du bestimmte Operationen auf die globalen Daten definieren kannst und diese als Methode in der FGV implementierst. Im Idealfall hat eine FGV keine eigentliche Get und Set Methode.