val(sgnl) vermeiden

(01.08.2011 12:58 )Kiesch schrieb:  Hmm... hier wird ja angesprochen, dass man val(sgnl) eventuell vermeiden sollte. Was genau ist dabei das Problem?

Alle UI Properties werden grundsätzlich im UI Thread ausgeführt. D.h. wenn Du ein val oder val(signal) Property in Deinem Programmcode ausführst, stellt LabVIEW den Code in eine Warteschleife um durch das Betreibssystem im Kontext des UI Threads aufgerufen zu werden. Nach dem dieser Code von Windows dann angekickt wurde (irgendwann us, ms oder was auch immer später) wird das ganze Spiel nochmals wiederholt, diesmal um den Codeteil wieder zum ursprünglichen Thread switchen zu lassen. Das daaaaaaaaaaaaaauert extrem lang im Verhältnis was normaler LabVIEW Code in der selben Zeit macht.

Wenn solche Properties in Deiner UI Ahandlungsschlaufe sind, wo Du auf Usereingaben reagierst, und zum Beispiel ein weiteres Even ankicken willst wenn ein davon abhängiges Userelement durch den Benützer manipuliert wurde, ist das absolut kein Problem. Die Threadcontextswitches sind unzählige Male schneller dann der meist geavanceerde Kungfu Kämpfer jemals Userelement anklicken kann.

Wenn Du dasselbe aber in Programmlogik in Deiner Applikation machst kann das einen grossen Einfluss auf die Reaktionszeit dieses Codeteiles haben. Oder noch schöner ein Property in einer langen Schlaufe. Einmal ein paar ms Threadswitchkontext ist kaum merkbar aber wenn das jedesmal in einer Schlaufe gemacht wird die 1'000'0000 mal ausgeführt wird macht das einen riesigen Unterschied. Ohne Propertynode läuft die Schleife meist in einigen 100ms durch. Mit Propertynode dauert es schnell mal 1 Minute oder mehr.