warum ist die Globale Variable schneller?

' schrieb:wenn ich das Register so gross mache wie ich es brauche (1024 Werte) wird das ganze sehr "langsam" ...

Zum einen: Array of Cluster of (.., String, ..) gehört so ziemlich zum Kompliziertesten, was der Speichermanager machen muss. Sollte der also die kompletten Daten kopieren müssen, hat er was zu tun!

Zum zweiten: Wie LV diesen Datentyp in den einzelnen Varianten - hier speziell Melder und Globale Variable - handhabt, weiß ich natürlich nicht. Ich kann mir aber gut vorstellen, dass LV zur Kompilierzeit im Falle einer GV bereits vieles macht, was bei Melder online, also zur Laufzeit, gemacht werden muss. Das liegt einfach an der unterschiedlichen Zielsetzung der beiden Typen.

Anzeige

Ja ich weiß dass ich hier nen Uralten Beitrag ausgrabe, aber der passt wohl ganz gut zu meiner Frage:

Warum wird immer geraten FGVs statt GVs zu verwenden? Soweit ich das bisher überblicke ist eine FGV doch durchaus etwas Fehleranfälliger als eine GV (man programmiert die sich selbst zusammen ^^) und bietet letztlich nur die gleiche Funktion die auch eine GV bieten würde (noch dazu muss man manuelles Fehlerhandling betreiben (also Fehlerfallgenerierung) was bei der GV gleich mitgeliefert wird (zumindest hat sie dafür Ein- und Ausgänge).
Laut dem Test hier ist eine GV außerdem schneller.

Warum also sollte man FGVs vorziehen?
(Anmerkung: Ich habe selbst noch nicht mit FGVs gearbeitet habe mich nur grade angefangen darüber schlau zu machen.)

(07.03.2011 17:16 )Kiesch schrieb:  was bei der GV gleich mitgeliefert wird (zumindest hat sie dafür Ein- und Ausgänge).

Fehlercluster bei globalen Variablen? Ist mir da was entgangen? Oder meist du mit Fehlercluster die SharedVariables?

Zitat:Warum also sollte man FGVs vorziehen?

Das kommt darauf an, was du machen willst.
In ein FGV kannst du ein Property einbauen, in eine GV nicht. Das Vermeiden von RaceConditions geht mit FGVs sehr einfach zu realisieren. Mit GV nur sehr schwer.

Ich nehme/empfehle meist die Single Element Queues. Sind flexibel und schnell und wenn bei Bedarf mit oder ohne Synchronisierung des Zugriffs und ggf. per Queuename adressierbar.
Der alte Benchmark hier im Thread ist gerade bei der SEQ Variante nicht repräsentativ.

Kleine Bemerkung zum Test-VI in Beitrag #1:
Die beiden Schleifen werden parallel ausgeführt. Es ist also möglich, daß die Auführungszeit jeder der beiden Schleifen durch die jeweils andere beeinflusst (verlängert) wird. Praktisch wirkt sich das vielleicht gar nicht aus, weil bei der Programmausführung doch nicht so hin- und hergesprungen wird wie es theoretisch der Fall sein könnte. Aber es bleibt - wenn es wie hier um die Zeitmessung geht - eine unsaubere Programmierung.
Und die Verwendung der Queue-Funktion "Status" statt "Element entfernen", war das wirklich Absicht?

@macmarvin

Ich verwende aktuell auch Queues - aber das war nicht die Frage
Genau deswegen hatte ich da ja auch nochmal nach Alternativen geschaut.

@IchSelbst

Zitat:Das Vermeiden von RaceConditions geht mit FGVs sehr einfach zu realisieren. Mit GV nur sehr schwer.

Okay klar, nehme an indem ich eine Sperrinfo auf die FGV setzt die der entsprechende Programmteil nachdem er fertig ist wieder entfernt - das leuchtet mir ein. Gibt das eigentlich eine Fehlermeldung wenn die FGV gerade von einem anderen Programmteil benutzt wird und ein anderer zugreifen (also das SubVI ausführen) will? (das darf ja logischerweise nicht reentrant sein) Oder wird dann einfach gewartet bis wieder verfügbar? Und wird hierbei nach "Anfragereihenfolge" abgearbeitet? (sprich: Wer zuerst angefragt hat ob er die Resource haben darf kriegt sie auch als erstes - das würde nämlich vermeiden, dass Raceconditions dadurch entstehen dass immer der gleiche Programmteil bei der Benutzung der Variable zum Zuge kommt)

@Fehlerhandling

Sorry, hab ich tatsächlich verwechselt. Nehme aber mal an die SV dürfte aufgrund der Netzwerkzugriffsfunktionen etc. im Zweifel deutlich langsamer sein.

@all

Noch ne zweite Frage. Ich habe bei meinem aktuell in Entwicklung befindlichen Programm aller Wahrscheinlichkeit nach eine Verteilung auf zwei verschiedenen Rechnern zu realisieren (leider ist noch nicht ganz für jeden Programmteil klar wo (also auf welchem Rechner) der laufen muss). Für mich erschienen dabei entweder TCP/IP oder SVs als die besten Optionen. Aktuell tendiere ich eher dazu es per TCP/IP laufen zu lassen und die entsprechenden in Frage kommenden Programmteile durch Queues zu kommunizieren zu lassen. Das sollte sich dann hinreichend einfach bei Bedarf in eine TCP/IP Kommunikation umwandeln lassen.

Allerdings bin ich mir weiterhin nicht sicher ob nicht vielleicht SVs vorzuziehen wären. Hab mit beidem noch nicht genug Erfahrung um das beurteilen zu können.

Anzeige

(08.03.2011 11:12 )Kiesch schrieb:  Okay klar, nehme an indem ich eine Sperrinfo auf die FGV setzt die der entsprechende Programmteil nachdem er fertig ist wieder entfernt - das leuchtet mir ein.

Kann man machen. Ist aber nicht notwendig: Kritische Operationen kann man in die FGV integrieren.

Zitat:Gibt das eigentlich eine Fehlermeldung wenn die FGV gerade von einem anderen Programmteil benutzt wird und ein anderer zugreifen (also das SubVI ausführen) will?

Nein, weil...

Zitat:wird dann einfach gewartet bis wieder verfügbar

Zitat:Und wird hierbei nach "Anfragereihenfolge" abgearbeitet?

Davon gehe ich aus. Das managet alles die LV-Runtime.

Zitat:Für mich erschienen dabei entweder TCP/IP oder SVs als die besten Optionen.

SVs sind halt um Potenzen einfacher zu handhaben. Dafür ist TCP/IP (UDP etc.) wahrscheinlich wesentlich schneller. Ich bevorzuge TCP/IP etc.

Muss man sich bei TCP / IP manuell darum kümmern die Verbindung am Leben zu erhalten (regelmäßige "Test"-Pings o.ä.) oder muss man sich nur einmal die Referenz auf die entsprechende Verbindung holen?
Und sollte man irgendwelche Prüfsummen mitsenden um die Datenintegrität zu gewährleisten oder wird das schon ausreichend vom TCP / IP Protokoll gehandhabt?


Ansonsten schonmal danke für die Erklärungen :-)

(08.03.2011 11:53 )Kiesch schrieb:  Muss man sich bei TCP / IP manuell darum kümmern die Verbindung am Leben zu erhalten (regelmäßige "Test"-Pings o.ä.)

JaNein.
Ja: Einmal der Handle weg, immer weg. Das ist der größte Nachteil. Zieht einer den Stecker raus, musst du die Verbindung neu starten
Nein: Ein regelmäßiges Bedienen der Schnittstelle ist nicht notwendig. Einmal offen - immer offen. (Wobei ich nie einen Versuch gemacht habe, ob nach 3 Stunden die Verbindung vom Betriebssystem getrennt wird, obwohl der Prozess noch läuft).

Zitat:Und sollte man irgendwelche Prüfsummen mitsenden um die Datenintegrität zu gewährleisten oder wird das schon ausreichend vom TCP / IP Protokoll gehandhabt?

Da ist TCP/IP ausreichend. Eigene Überprüfung schadet aber nicht.

(07.03.2011 22:53 )macmarvin schrieb:  Ich nehme/empfehle meist die Single Element Queues.

Leider werden die wirklich entscheidenden Hinweise oft nicht beachtet - so auch dieser. Im VI "Speedtest" verringert sich bei Umstellung von Melder auf Single-Element-Queue die Ausführungsdauer von ca. 14 ms auf 0 ms - ist dann also auch unschlagbar besser als mit lokelen V., globalen V., FGV und was sonst hier alles diskutiert wird.

  speedtest2.vi (Größe: 15,6 KB / Downloads: 160)