property node ... wirklich langsam...

Hallo,

ich arbeite an einem wirklich umfangreichen Projekt mit einer State-Machine die gewachsen und gewachsen ist (barocke Programmierung weil niemand den Aufwand eines generellen Redesigns übernimmt) ... das Main VI ist fast 4MB groß.

OK, mein Erstaunen die States mit vielen Prpoperty-Nodes sind echt langsam... z.B.: das in der Anlage (oben passiert nur ein wenig Mathematik) brauch 3000ms... ich bin verblüfft.

Hat jemand eine Erklärung?

Ich danke Euch

Gottfried

Anzeige

(16.02.2019 10:21 )gottfried schrieb:  OK, mein Erstaunen die States mit vielen Prpoperty-Nodes sind echt langsam... z.B.: das in der Anlage (oben passiert nur ein wenig Mathematik) brauch 3000ms... ich bin verblüfft.

Das ist ein alter Hut. Setzen von Property Nodes war schon immer langsam, da jede Property Node einen Wechsel in den UI-Thread erzwingt und ein Frontpanel-Update auslöst.
vgl. z.B. hier

Gruß, Jens

Die eigentlich interessierende Frage ist aber, wie man mit dieser Langsamkeit umgeht. Keine Eigenschaftsknoten in der zeitkritischen Haupschleife. Und wenn doch: Den Knoten nur bei Wertänderung aufrufen, also den Knoten in einen Case setzen, Wertänderung prüfen, und nur wenn "True" den Knoten aufrufen. Der Normalfall ist aber eine gesonderte parallele Schleife für (Wertänderungs-)Ereignisse. Dort können Eigenschaftsknoten in der Regel ohne Bedenken verwendet werden.
Und natürlich: Statt der Eigenschaft "Wert" besser eine lokale Variable verwenden.
Was ich nicht weiß, noch nicht geprüft habe, aber gern mal wissen möchte: Bringt es eine zeitlichen Vorteil, wenn ich fünf Eigenschaftsknoten mit je einer Eigenschaft zu einem einzigen Knoten mit 5 Eigenschaften zusammenfasse? Oder ist das egal?. Weiß das jemand?

(17.02.2019 16:29 )Lucki schrieb:  Die eigentlich interessierende Frage ist aber, wie man mit dieser Langsamkeit umgeht.

Das habe ich doch in meinem Link beantwortet: Delay Front Panel Update anwenden, so dass am Schluss nur 1 Wechsel in den UI-Thread erzeugt wird.

(17.02.2019 16:29 )Lucki schrieb:  Was ich nicht weiß, noch nicht geprüft habe, aber gern mal wissen möchte: Bringt es eine zeitlichen Vorteil, wenn ich fünf Eigenschaftsknoten mit je einer Eigenschaft zu einem einzigen Knoten mit 5 Eigenschaften zusammenfasse? Oder ist das egal?. Weiß das jemand?

Meines Wissens nach bringt das nichts. Jedes Element in so einem aufgezogenen Eigenschaftsknoten wird einzeln bearbeitet. Das sieht man z.B. daran, dass bei einem Fehler (z.B. Plotfarbe eines nichts existierenden Plots setzen) erst die Eigenschaft ab der fehlererzeugenden Eigenschaft nicht mehr bearbeitet werden.

Gruß, Jens

(18.02.2019 09:09 )jg schrieb:  

(17.02.2019 16:29 )Lucki schrieb:  Die eigentlich interessierende Frage ist aber, wie man mit dieser Langsamkeit umgeht.

Das habe ich doch in meinem Link beantwortet: Delay Front Panel Update anwenden, so dass am Schluss nur 1 Wechsel in den UI-Thread erzeugt wird.

Also wenn "Delay FP Update" True ist, wird ein Eigenschaftsknoten, wenn er wiederholt ohne Wertänderung aufgerufen wird, gar nicht mehr ausgeführt? Das ist ja sensationell!. Zwar konnte ich das aus der Hilfe dazu nicht direkt herauslesen, aber wenn Du es sagst glaube ich es gern. Vielen Dank!

(18.02.2019 10:15 )Lucki schrieb:  Also wenn "Delay FP Update" True ist, wird ein Eigenschaftsknoten, wenn er wiederholt ohne Wertänderung aufgerufen wird, gar nicht mehr ausgeführt? Das ist ja sensationell!. Zwar konnte ich das aus der Hilfe dazu nicht direkt herauslesen, aber wenn Du es sagst glaube ich es gern. Vielen Dank!

Doch, er wird ausgeführt. Es wird bloß nicht der Wechsel in den UI-Thread und damit ein FP-Refresh ausgelöst. Und nicht vergessen: Nachdem die ganzen PropertyNodes geschrieben wieder, muss diese "Delay FP Update" Eigenschaft wieder auf FALSE gesetzt werden, sonst gibt es gar keine FP-Updates mehr.

Gruß, Jens

Anzeige

Die noch nicht beantwortete Frage ist doch aber die, warum es 3s dauern soll, das bisschen Skaliererei durchzuführen.
Dass Eigenschaftsknoten längen dauern als keine, wird Gottfried auch gewusst haben...

Kann es nicht sein, dass die Zeit irgendwo in einem der vermeintlichen "nur-Mathematik-VIs" verlorengeht oder in Eigenschaftsknoten außerhalb des gezeigten Bildes?


Gruß, Marko

(18.02.2019 11:19 )Trinitatis schrieb:  Die noch nicht beantwortete Frage ist doch aber die, warum es 3s dauern soll, das bisschen Skaliererei durchzuführen.
Dass Eigenschaftsknoten längen dauern als keine, wird Gottfried auch gewusst haben...

Kann es nicht sein, dass die Zeit irgendwo in einem der vermeintlichen "nur-Mathematik-VIs" verlorengeht oder in Eigenschaftsknoten außerhalb des gezeigten Bildes?


Gruß, Marko

Da hast du natürlich vollkommen Recht.

Operationen an Graphen (falls der Graph der Hauptverursacher ist) werden aus meiner Erfahrung langsam, wenn sie extrem viele Plot und/oder extrem viele Daten darstellen. Vielleicht ist das das Problem.

Gruß, Jens

Erst einmal ein großes DANKE ... habe viel gelernt. Nein, die Mathe ist schlicht - im Vergleich zu anderen States. Ich denke _nun_ das die Langsamkeit (3 sec) daher rührt da das FP im wesentlichen aus 3 Tab-Controls mit in Summe 30 Tabs besteht ... viele voll mit Diagrammen. Bin ich auf der richtigen Spur?

Danke

Gottfried

(18.02.2019 11:57 )gottfried schrieb:  ...Ich denke _nun_ das die Langsamkeit (3 sec) daher rührt da das FP im wesentlichen aus 3 Tab-Controls mit in Summe 30 Tabs besteht ... viele voll mit Diagrammen...

Gottfried

Wenn aber das FP-update das Problem ist, dann hätte ich ja glatt gedacht, dass nur die sichtbaren Controls upgedated werden und nicht alle auf allen deiner 30 tabs.
Oder wird grundsätzlich alles neu gezeichnet?

Gruß, Marko