Performance penalty with property nodes?

[MogaRaghu]

In a specific application I have a front panel with three combo boxes and another three string indicators. Based on the selections made in the combo boxes, various messages will have to be displayed in the string displays. This naturally calls for multiple instances in the same VI where the combo boxes will have to be read and string display updates.

One choice would have been local variables ( of combo boxes & string indicators ) for passing the values around. But since this is going to make several copies and hit performance, I decided to use property nodes. And it works fine.

The question is, whether excessive use of property nodes has any adverse effect on performance ?

Thanks

Raghunathan

[altenbach]

If you are talking about writing to "value properties", this method is definitely the least efficient, much more expensive than even local variables. Are you sure you cannot use direct wires???

(Writing just a few properties if needed is typically not a problem. Place them in a case structure so they're only updated when the values change, and not over and over with each loop iteration.)

If you could post a simplified version of your code, maybe we can suggest a few hints. 🙂

[rolfk]

Everything altenbach said is correct. Using the Value property is a very bad idea if you do that repetitively in that way. A single update, for initialization for instance, is alright but to update any control in a loop through a value property is almost always (99.9999% of the cases) the wrong thing to do.

I just want to add to this that it is more effeicient to use one single property node modifications of property nodes cause a redraw of the control of some sorts and if you combine multiple property changes into one node the redrawing is only done once after all the new properties have been applied.

Rolf Kalbermatter

[Mark H]

I don't really follow why you need to read your combo boxes, and write to your string indicators at multiple instances within the same vi - using loops, case structures or state machines, I would have thought you ought to be able to construct a way of processing the singular input terminals to singular output terminals - this would almost certainly result in more predictable behaviour (avoid possible "race conditions") and supportable code.

If you really must use multiple property nodes - I really wouldn't worry about any performance issues. Given that you are dealing with the user interface, there is no way that you will notice any performance difference - the PC is incredibly fast, and the human operator is incredibly slow by comparison.

Even when writing data to controls via property nodes in a loop - although there may be a slight performance penalty, it's often not of any real significance unless you are trying to run a really high performance intensive loop.

In one of my applications, I write/update five or six different plots to a single XY graph that is on the front panel of a different VI, by passing a reference to the graph and accessing by the "value" property node. The loop involves, data aquistition, processing (inc FFT etc) unbundling of the plot bundles/arrays, appending the new data points, rebundling and writing to the "value" property node - the PC handles all of this at a rate of about 50 times a second (much faster than an observer can perceive) without any problem.

So don't worry too much about such performance issues - in many cases the issue is of no significance, unless you are in a very "intensive loop".

Mark H.

[MogaRaghu]

>> If you could post a simplified version of your code, maybe we can suggest a few hints.

Of course - I have tried to simplify the whole thing and tried to create a simple VI.

There are two combo boxes - the first one is to select the Model A or B and based on each model there are three different tests that can be selected for each model. Thus the user can select one among 6 tests. And midway through the test, if the test is stopped, the details of the test are saved to disk. When the application is launched next, the last run setup is recovered from the disk so that the incomplete test can be continued.

Since there are many places where the contents of the combo and String display are to be updated, I thought the property node was a simple way to do it.

( The actual application has 6 models and each model has a minimum of 5 tests and in each test there could be atleast 8 variants . You can imagine the extent of tracking mechanism required )

Just unzip the contents of the zip file into any folder and run. ( LV7 + WIN_XP )

Any idea to improve the situation is most welcome.

Thanks

Raghunathan

[altenbach]

I think your version is LabVIEW 7.1. Anyway, you should be able to dramatically simplify the code.

With a few simple changes, I was able to get it down to a single property node and two local variables. See attached. I am sure many improvements are possible.

Message Edited by altenbach on 06-21-2005 09:26 AM

[altenbach]

A few more comments:

You create a race condition, because you try to set the value of the combo box 2 before the strings are set. For example, if you stop your VI with Model B, next time you would get a value that does not exist, because combo box 2 still hase the "A" strings. You need to write the strings[] first according to the value from file 1, the set the value from file 2.

Don't use string manipulation to create file names. Use the proper built path tools so the VI is platform independent.

You only need to create the paths once!

If you have an event structure, you don't need any wait statements.

Sequence structures are rarely needed.

You overwrite the current file from position 0. If the existing string in the file is longer than what you write, you retain the "tail" of the previous value, creating an nonexisting item.

I cleaned it up a bit further and implemented fixes for these points (LabVIEW 7.1). 🙂

[MogaRaghu]

Hi Altenbach,

The ComboComboMod2.vi was quite elegant. Reason why I gave it a 5 star rating!

Yes, optimizations like creating the path once and re-using it, deleting the file and then using the duplicate path to write charcters ( I liked it ) are good ideas. They save many redundant functions.

So at the end of it do we conclude that wires / shift registers are the best alternatives when compared to local variables or property nodes ? And if it is absolutely required, then MAYBE use some local variables. Over use of either local variables or property nodes is bad for health (of the VI).

Thanks

Raghunathan

[altenbach]

Thanks! I would suggest to just do the experiment. 🙂

The attached little demo (LabVIEW 7.1) does the same thing (increment a I32 variable in a loop) in three different ways:

-- shift register
-- local variable
-- value properties

On my slow laptop, 10000 iterations take the following total time in ms.

shift registers: 3ms
Local variables: 5ms
Value Properties: 1891ms (!!)

Notice that the shift register solution would be much faster (more than 10x (or 1000000 in 20ms)) if the indicator is placed outside the loop, the only thing slowing it down is the update of the indicator.

In conclusion value properties are much more expensive than local variables or shift registers. If you just write once e.g. at the beginning of the program, it does not really matter, but once you do things repetitively in a loop, the costs add up. I always prefer wires because they also make the diagram easy to follow. Local variables break the dataflow and can cause race conditions. They have their limited use, especially in user interface related code. They have no business in pure computations. 🙂

[MogaRaghu]

Hi Altenbach,

Congratulations on becoming a LabVIEW Champion.

I am happy I raised this question on Property Nodes. Or rather my next client in line will be happy to get a code that is fast and does not violate the basic tenements of a programing language.

Thanks for all the support.

Regards

Raghunathan