Faraclas wrote:
> Ed,<br><br>I will have to respectfully disagree with you on this one.
> My understanding is that the UI tread only needs to run for something that
> needs to repaint the control (data writing). Data reading should just access
> the values from memory, make a copy into the new wire and off you go.
But this needs to be synchronized with the UI thread nevertheless.
LabVIEW chooses to optimize terminal access and local variables and
penalize reference value access due to the fact that the first can be
easily analyzed in true dataflow while the last will break dataflow in
many ways. The biggest roadblock however to even try to optimize
reference value access is the fact that the VI server in LabVIEW is a
very complicated entity to manage and all property nodes go eventually
through VI server in some way. Rather than having only an almost perfect
multi-threading capable VI server, the LabVIEW developers choose to be
on the safe side protect any access through VI server and in that way
make sure your applications won't misterically crash on completely
unrelated things due to race conditions.
> Anyways,
> It is probable that you are right on a theoretical basis; however I have
> built large applications with 100s of controls and indicators as my data
> containers and do not notice any speed degradation as a result.
The number is not the problem. The fact that you may try to access
property nodes either in some part of your application which needs to
have almost realtime behaviour or in a place which is called 100 times a
second will make your application misbehave or crawl however.
> Also, there are many many times when you need to access properties.
Yes but this is typically based on user actions and even the fastest
user will not generate more than a few events per second.
> And since this cannot be done with local variables, you are stuck wtih
> the propery nodes. Therefore, if you are going to access a property
> anyways, why create an additional local variable?<br><br>As far as your
> comment on bad programming, it is my opinion that messy (i.e. too many
> wires) constitutes a poor program.
While I agree that to many wires is a messy thing, it is not a question
of to many wires OR using value properties all over the place. It is a
question of applying proper architectures such as while loops with shift
registers, state machines, intelligent global variables and such things
if you get a messy application or not.
Rolf Kalbermatter