Implicit vs. Explicit Property Node: Performance Difference?

[mplynch]

Is there a performance difference between implicitly and explicitly linking a property node to a control or indicator?  I tend to use the explicit variety unless I'm getting a reference to a control/indicator as an input to a sub-VI.  I'm curious if that's considered good practice.

 

Also, when using the explicit variety, does LabVIEW handle cleaning up the control/indicator reference?  It's my understanding that if you create a reference to pass to an implicitly linked property node you need to close it to free up the reference.  I haven't been doing that with the explicit nodes since the whole point, in my mind, of you using them is brevity.

 

Thanks in advance for your help!

[eberaud]

Well with an explicit node (is that an official wording?) you don't get a reference, so you couldn't close it anyway even if you wanted to 

[mplynch]

Well with an explicit node (is that an official wording?) you don't get a reference, so you couldn't close it anyway even if you wanted to 

 

Doh!  That was stupid.  Of course, you're right...

 

Still curious about the best practice/efficiency bit...  Oh, and I totally made up that name.  I don't know if there's an official term for it.  Either way, you seem to have understood what I meant, so I stand by it!

Edited March 5, 2015 by mplynch

[ned]

According to NI's terminology (http://www.ni.com/white-paper/3159/en/), you have implicit and explicit backwards. An implicit property node is one where the reference is not explicitly wired in.

 

You do not need to close references to controls and indicators, although there's no harm in doing so. You can search the NI forums for more details, but the short version is, a front-panel control or indicator is a static object. All references to a single front-panel item have the same value, and you can't invalidate such a reference (the reference stays valid even if you close it because the front-panel items still exists), so closing such a reference is a no-op. You DO need to close references to objects that are created dynamically (.NET and ActiveX objects, for example).

 

Sorry I don't have an answer on your actual question about whether there's a performance difference.

[ak_nz]

My understanding is that they both execute in the single UI thread and they have basically the same performance - although the performance similarity is unofficial from an NI support person.

[drjdpowell]

Also, when using the explicit variety, does LabVIEW handle cleaning up the control/indicator reference?  It's my understanding that if you create a reference to pass to an implicitly linked property node you need to close it to free up the reference. 

 

No.  Those are static references that don’t need to be closed (closing them does nothing, so don’t bother closing them).  You can tell if a reference is static by probing it to see if it changes on each call (if it doesn’t, it’s static).

[hooovahh]

There are several discussions on LAVA about what references should and shouldn't be closed.  The statement that I think holds true about 90% of the time is "If I did something to open a reference in my code, then I need to close that reference".  Did I use OpenVI reference?  Then I need to close it.  Did I use a reference tied to a control?  Or the ThisVI reference?  Then I don't need to.  It starts to get a little confusing with things like an invoke node that can give you a reference to an already open thing.  But throwing close references around shouldn't cause any problems.  LabVIEW will try to close that reference, and realize it can't for some reason, like the VI that owns a control is still in memory and it won't do anything.

 

I've often wrote a simple VI that is just a while loop that runs forever, which will perform some kind of operation that I think might be making new references, over and over without closing.  Then I'll look at the memory usage in the Task Manager.  If it doesn't go up, then that reference doesn't need to be closed, if it does then I need to close it.

[Rolf Kalbermatter]

There are several discussions on LAVA about what references should and shouldn't be closed.  The statement that I think holds true about 90% of the time is "If I did something to open a reference in my code, then I need to close that reference".  Did I use OpenVI reference?  Then I need to close it.  Did I use a reference tied to a control?  Or the ThisVI reference?  Then I don't need to.  It starts to get a little confusing with things like an invoke node that can give you a reference to an already open thing.  But throwing close references around shouldn't cause any problems.  LabVIEW will try to close that reference, and realize it can't for some reason, like the VI that owns a control is still in memory and it won't do anything.

 

I've often wrote a simple VI that is just a while loop that runs forever, which will perform some kind of operation that I think might be making new references, over and over without closing.  Then I'll look at the memory usage in the Task Manager.  If it doesn't go up, then that reference doesn't need to be closed, if it does then I need to close it.

 

Traditionally all references needed to be closed. This changed around LabVIEW 7.1 for control references. But closing them anyways doesn't hurt as the Close Reference is simply a noop for them.

 

A quicker way to check if you cause memory leaks by not closing a reference is to just typecast it into an int32 and execute it twice. If the numeric value doesn't chance it is a static refnum and doesn't need to be closed. But generally I never do that. The thumb of rule is simple, iIf it is a control reference it doesn't need to be closed, anything else needs closing. And closing a control reference that doesn't need to be closed doesn't hurt so err on the safe side.

 

Ohh and as far as performance difference: You really can spend your valuable developer time much better than worrying about such sub microsecond optimizations. The difference is likely negligable, and definitely to small for me to worry about.

[ShaunR]

A quicker way to check if you cause memory leaks by not closing a reference is to just typecast it into an int32 and execute it twice. If the numeric value doesn't chance it is a static refnum and doesn't need to be closed. But generally I never do that. The thumb of rule is simple, iIf it is a control reference it doesn't need to be closed, anything else needs closing. And closing a control reference that doesn't need to be closed doesn't hurt so err on the safe side.

 

This is probably something NI could easily do for us just by colour coding.

[eberaud]

This is probably something NI could easily do for us just by colour coding.

 

Sounds like one of the best Idea Exchange topic ever 

[mplynch]

Ohh and as far as performance difference: You really can spend your valuable developer time much better than worrying about such sub microsecond optimizations. The difference is likely negligable, and definitely to small for me to worry about.

 

You're absolutely right: that's what you fine folks are for!

 

The question was academic... just trying to learn!

Edited March 10, 2015 by mplynch