+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Melder Performance (/Thread-Melder-Performance)
Seiten: 1 2
Melder Performance - D_Sev - 05.09.2014 21:49
Moin zusammen,
ich habe gehört, dass das häufige Erstellen und Zerstören von Meldern zwecks synchroner Kommunikation nicht sehr performant sein soll.
Statt dessen solle man lieber einen Vorrat an Meldern anlegen und aus diesem Fundus schöpfen. Ich kann das nicht so recht glauben und wollte deshalb einmal einen Performance-Vergleich anstellen.
Aber nach müde kommt doof und ich bin grade nicht in der Lage den Fehler in meinem VI zu finden.
Wähle ich die Variante mit der FGV aus, können Nachrichten zu den falschen Schleife gelangen und es entsteht ein Fehler. Debuggen kann ichs nicht so richtig. Lege ich eine Probe an einem Melder an, verändere ich die Geschwindigkeit so, dass der Fehler nicht mehr auftritt.
Vielleicht kann mir jemand meinen Denkfehler aufzeigen.
RE: Melder Performance - D_Sev - 06.09.2014 08:43
LabVIEW 2011
RE: Melder Performance - GerdW - 06.09.2014 09:45
Hallo Sev,
Anmerkungen zur FGV:
- Im Case "Get Notifier" suchst du anscheinend nach einem bisher unbenutzten Notifier. Da ist aber kein Fehlerhandling, falls keine freier Notifier gefunden wurde! Noch schlimmer: welcher Notifier wird in eben diesem Fall gewählt, wenn die Search1DArray-Funktion ein "-1" ausgibt?
- Zweites Problem mit der FGV: die FGV blockiert gleichzeitige Aufrufe, das ist ihr primärer Einsatzzweck. Bei deinem MainVI führt dies aber dazu das sich alle Schleifen gegenseitig ausbremsen: Andauernd und ungebremst wird versucht, auf die FGV zuzugreifen…
- Bist du dir in deiner Testroutine sicher, dass deine Testschleifen wirklich ein Signal ihres Notifiers erhalten? Wird genau dieser Notifier wirklich beschrieben? Wenn ich das mit ganz normalem Debugging mit Sonden überprüfe, bekomme ich da ganz komische Resultate…
Allgemeine Anmerkungen:
Ich glaube, das ganze Gestrüpp ließe sich deutlich lichten, wenn du deine Notifier "benamsen" würdest!
Man kann jedem Notifier/jeder Queue einen Namen zuweisen. Damit ist für alle an der Kommunikation beteiligten Parteien der Notifier/die Queue bekannt und jede Partei öffnet für sich einmal eine Referenz und schließt diese einmal ganz am Ende.
Wozu also dieses andauernde Öffnen/Schließen oder gar fehlerhafte Verwalten in einer FGV?
P.S.: Das AutoCleanup-Tool hätte zumindest bei der FGV auch nicht geschadet…
RE: Melder Performance - jg - 06.09.2014 10:38
Dein VI ist ein schönes Beispiel dafür, wieso ich persönlich nach Jahren LabVIEW immer noch nicht richtig warm werde mit Notifiern.
Problem ist, dass du eigentlich eine 1-zu-1 Kommunikation brauchst, der Notifier aber eine 1-zu-N Kommunikation liefert.
Fangen wir bei der Obtain/Destroy Variante an:
Durch das dauernde Erstellen eines neuen Notifiers, den du jeweils nach einmaliger Verwendung wieder zerstörst, stellst du "manuell" die 1-zu-1 Kommunikation sicher. Die jeweils zweite Schleife rechts meldet immer genau an den Aufrufer zurück, und danach ist der Notifier weg. Es kann also nichts schief gehen.
Das Ganze würde natürlich genauso sicher funktionieren, wenn du die Notifier jeweils vor der Schleife nur 1x erzeugst:
[attachment=50676]
Jetzt zur FGV-Variante:
Erster (kleiner) Fehler: In der untersten For-Schleife ist die Notifier-Refnum nicht weitergegeben.
Das ist aber nicht das Haupt-Problem, wieso diese Variante nicht wie gedacht funktioniert. Das eigentliche Problem ist hier die 1-zu-N Funktionalität des Notifiers. Ich skizziere das mal an Hand von 2 Prozessen. Es könnte Folgendes passieren:
Prozess 1 holt sich die Refnum von Notifier 1 aus dem FGV. Diese gibt sie per Queue an den Parallel-Prozess 1 weiter und wartet jetzt auf eine Meldung. Der Parallel-Prozess 1 sendet diese Meldung dann irgendwann, und es geht in Schleife 1 weiter, die Refnum wird wieder freigegeben.
Prozess 2 wird erst jetzt gestartet (ist ja alles parallel programmiert), holt sich jetzt ebenfalls die Refnum von Notifier 1 (der ist ja wieder frei verfügbar), gibt sie an den Parallel-Prozess 2 weiter, und startet ein "Wait on Notification". Und hier kann es schon schief gehen. Ein "Wait on Notification" wartet nicht ab Aufruf auf eine neue Meldung, sondern wartet pro Instanz auf eine Meldung. Diese Instanz hat die Meldung aus Prozess 1 aber noch nicht ausgelesen, das ist für diese Instanz also eine neue Meldung. Sie wird somit ausgewertet und schon hast du einen Fehler.
Jetzt könntest du probieren, das Ganze mit einem "True" am Eingang "Ignore Previous" am Eingang von "Wait on Notification" zu umgehen. Somit würde Prozess 2 zumindest nicht die Notification von Prozess 1 auswerten. Das funktioniert aber auch nicht sauber, denn auf Grund des Multi-Threading von LabVIEW könnte jetzt Folgendes passieren:
- Prozess 2 holt sich Notifer 1 und gibt ihn per Queue weiter.
- Der Parallel-Prozess 2 liest Notifer 1 aus und sendet sofort die Meldung.
- Erst jetzt startet Prozess 1 das "Wait on Notification", wegen "Ignore previous" erhält er aber gar keine Meldung.
Folge: Stillstand.
Mögliche Lösung für die FGV-Variante: Umstieg auf 1-Element Queues anstatt des Notifiers. Denn dann hast du wieder eine saubere 1-zu-1 Kommunikation.
--
Und dann noch zu deinem "ich habe gehört": Keine Ahnung, woher du das hast, ich kenne nur den Hinweis aus der Hilfe, der sich aber auf den Speicheranstieg bei "Obtain Notifier" bezieht:
Zitat:If you use the Obtain Notifier function to return a reference to a named notifier inside a loop, LabVIEW creates a new reference to the named notifier each time the loop iterates. If you use Obtain Notifier in a tight loop, LabVIEW slowly increases how much memory it uses because each new reference uses an additional four bytes. These bytes are released automatically when the VI stops running. However, in a long-running application it may appear as if LabVIEW is leaking memory since the memory usage keeps increasing. To prevent this unintended memory allocation, use the Release Notifier function in the loop to release the notifier reference for each iteration.
Also eigentlich ganz was anderes.
Die FGV-Variante wird übrigens durch die "Shared Resource" FGV immer langsamer sein...
Gruß, Jens
--
Edit: "Moin zusammen" um 11 Uhr nachts...
(06.09.2014 09:45 )GerdW schrieb: P.S.: Das AutoCleanup-Tool hätte zumindest bei der FGV auch nicht geschadet…
, die 2012-Variante vom FGV sieht IMHO schön aus, die 2011er habe ich mir nicht angeschaut. Kein Bedarf AutoCleanUp.
RE: Melder Performance - jg - 06.09.2014 11:20
Hier ein kleines VI, das die "Memory-Funktion" des Notifiers verdeutlicht: Obwohl 4x "Wait On Notification" verwendet wird, läuft das VI ganz normal durch.
[attachment=50677]
Und anbei die VIs, umgebaut auf Queue anstatt Notifier. Geht jetzt ohne Probleme.
@GerdW:
(06.09.2014 09:45 )GerdW schrieb: Anmerkungen zur FGV:Prinzipiell hast du Recht, praktisch werden in dem Beispiel aber max. 7 Notifier-Refnums parallel gebraucht.
- Im Case "Get Notifier" suchst du anscheinend nach einem bisher unbenutzten Notifier. Da ist aber kein Fehlerhandling, falls keine freier Notifier gefunden wurde! Noch schlimmer: welcher Notifier wird in eben diesem Fall gewählt, wenn die Search1DArray-Funktion ein "-1" ausgibt?
Gruß, Jens
RE: Melder Performance - D_Sev - 06.09.2014 11:48
(06.09.2014 09:45 )GerdW schrieb: - Im Case "Get Notifier" suchst du anscheinend nach einem bisher unbenutzten Notifier. Da ist aber kein Fehlerhandling, falls keine freier Notifier gefunden wurde! Noch schlimmer: welcher Notifier wird in eben diesem Fall gewählt, wenn die Search1DArray-Funktion ein "-1" ausgibt?
Stimmt, aber da ich nur "kurz" einen Performance-Test machen wollte, habe ich einfach mal zur Sicherheit mehr Melder erstellt als in Gebrauch sein können.
(06.09.2014 09:45 )GerdW schrieb: - Zweites Problem mit der FGV: die FGV blockiert gleichzeitige Aufrufe, das ist ihr primärer Einsatzzweck. Bei deinem MainVI führt dies aber dazu das sich alle Schleifen gegenseitig ausbremsen: Andauernd und ungebremst wird versucht, auf die FGV zuzugreifen…
Genau deshalb war/bin ich auch skeptisch, das ich auf diese Weise einen Performance-Vorteil erreichen könnte.
(06.09.2014 10:38 )jg schrieb: Und dann noch zu deinem "ich habe gehört": Keine Ahnung, woher du das hast, ich kenne nur den Hinweis aus der Hilfe, der sich aber auf den Speicheranstieg bei "Obtain Notifier" bezieht:Nur Hörensagen
Danke für die fundierte Antwort. Macht natürlich alles Sinn.
(06.09.2014 11:20 )jg schrieb: Und anbei die VIs, umgebaut auf Queue anstatt Notifier. Geht jetzt ohne Probleme.
Und Tadaa..ein satter Performance Gewinn von -100%
RE: Melder Performance - jg - 06.09.2014 12:07
(06.09.2014 11:48 )D_Sev schrieb: Und Tadaa..ein satter Performance Gewinn von -100%Aber genau hingeschaut, der Obtain/Destroy Fall erzeugt in meinem VI die Queues nur 1x VOR der Schleife. Gerade das bringt Performance - und führt (hoffentlich) zu weniger Speicherfragmentierung als dauerndes Neu-Erstellen.
Gruß, Jens
EDIT: Wenn ich Obtain/Destroy wieder in die Schleife mit reinnehme, dann ist die FGV-Variante trotz Shared Resource wieder schneller!!!
RE: Melder Performance - D_Sev - 06.09.2014 12:40
Hmm,
und das mit dem Ausgliedern vor die Schleife, kann ich auch nicht für alle meine Anwendungen so nutzen.
Ich habe z.B eine Messenger-VI, welches es mir ermöglichen soll, von überall aus Nachrichten an einen Prozess X zu schicken. Dabei kann man frei wählen, ob auf eine Antwort gewartet werden soll oder nicht. In diesem Fall seh ich keine einfache Möglichkeit das auszugliedern.
Und im Beipiel bestand die Notification jetzt nur aus einem String. Ich denke, wenn man den Datentyp komplexer anlegt, steigt der Gewinn durch die FGV-Variante.
RE: Melder Performance - jg - 06.09.2014 14:57
In deinem letzten Screenshot sind benamte Queues und Notifier zu sehen, da trifft dann wieder der Hinweis aus der Hilfe mit dem Speicher"leck" zu. Dort also aufgepasst.
Gruß, Jens
RE: Melder Performance - D_Sev - 06.09.2014 15:43
Wollte doch nur die Anwendung zeigen bei der es nicht so einfach möglich ist die Erstellung des Melders auszugliedern
Nur für den Fall das dort jemand direkt einen besseren Lösungansatz sieht.
Die benamte Queue, die im Prozess ausgelesen wird, wird im Messenger eigentlich nicht erstellt sonder aus einer FGV bezogen(War nur besser für mein Konzeptbild). Der Notifier ist auch im Bild nicht benamt.