Unerwarteter Performance-Einbruch

Ich bin auf der Suche nach einer Erklärung für ein mir nicht plausibles Verhalten.


Ich habe 6 Instanzen eines reentranten VI's. Diese VI's führen alle kontinuierlich Berechnungen aus und senden alle pro Durchlauf ihr Ergebnis über ein Melder-SubVI an den ein und den gleichen Empfänger.

Das Melder-VI hat einen FGV-charackter und ist deshalb nicht reentrant.

Mein Gedanke war nun folgender: Da 6 "parallele" Schleifen ein und das selbe VI aufrufen, habe ich hier vermutlich eine Art Flaschenhals.

Also mache ich diese VI doch reentrant, rufe es aber in den einzelnen Instanzen per "Call by Reference" auf um den FGV-charackter für die einzelnen Instanzen beizubehalten.

Erwartet hätte ich nun alles von einer leichten Verbesserung der Performance bis zu einer leichten Verschlechterung. Aber ...

Ergebnis: Bei einer Testsequenz, die verteilt auf die 6 VI's ,1200 mal eine simple Berechnung ausführt und das Ergebnis zurücksendet, habe ich mich von ca. 10s in der alten Version auf ca 55s in der neuen Version verschlechtert.

(Die Initialisierungs-Phase ist in dieser Testsequenz nicht inbegriffen, d.h. die einzige Änderung ist der unterschiedliche Aufruf des Melder-VI's)

Anzeige

Die Testsequenz wird ja von Codeumfang her überschaubar sein. Lade sie doch einfach mal hoch.

Der Aufruf eines VI per "Call by Reference" ist üblicherweise deutlich langsamer. Außerdem musst du da aufpassen, dass das VI wirklich "Reentrant" aufgerufen wird.

So ganz verstehe ich auch nicht die Verwendung eines Melders. Wenn ich die Ergebnisse von 6 Instanzen über dieselbe Kommunikationsschiene weitergeben will, dann würde ich zu einer Queue greifen, damit ich wirklich von allen Instanzen das Ergebnis bekomme. Über einen Melder bekomme ich immer nur das Ergebnis von 1 Instanz, es könnten Ergebnisse anderer Instanzen verloren gehen.

Wie Lucki geschrieben hat, VIs (mglw. auch abgespeckte) wären zum besseren Verständnis hilfreich.

Gruß, Jens

Also nachdem was ich so gelesen habe, ist ein Aufruf per Reference nur unwesentlich langsamer als der eines normalen SubVI's.

Ich verwende natürlich Queues..das ist bei mir im Kopf irgendwie falsch verlinkt, sodass ich ich immer Melder sagen. Und offensichtlich sogar schreibe^^

Aber das Problem hat sich auf seine Weise jetzt auch erledigt. Wenn ich das Programm abspecke, lässt sich der Fehler nicht mehr reproduzieren.

Gefunden habe ich aber auch das hier:

"Be aware that calling a VI with the Call By Reference Node involves a small overhead compared with a normal SubVI call, due to validating the VI reference and some other bookkeeping. This is, however, insignificant with all but very small VIs when used on local machines. It can become a problem with frequent calls to remote machines."

Aha, Queues, dann passt alles.
Ich würde das folgendermaßen aufziehen:
Die Queue-Refnum wird einmal bei Programmstart erzeugt und entweder per Globaler Variable oder per FGV verteilt. Die "Erfassungs-VIs" holen sich diese Refnum in ihrer Initialisierungsphase und merken sie sich dann per Schieberegister. Schreiben in Queue dann einfach per "Enqueue Element". Dafür kann man ein eigenes SubVI erstellen, mit der Queue-Refnum als Ein- und Ausgang. Wenn dieses SubVI als "Reentrant" definiert wird, dann kann es auch mehrfach parallel aufgerufen werden.

Gruß, Jens