Inlineable property nodes / Invoke nodes when apporopriate

[Intaris]

According to my understanding and the following discussion:

http://forums.ni.com/t5/LabVIEW/Why-exactly-can-t-I-inline-this/td-p/3126562

certain types of Property nodes and Invoke nodes should be inlineable without any great problems.

I would suggest that the LabVIEW compiler get's a bit smarter about this aspect of limiting the ability to inline code.  If there's no technical limitation regarding inlining of a property node or Invoke node which is fed with a reference (which does not originate from a local object i.e. a static reference to a FP object) then it should be inlineable.

[Dragis]

I'm all for optimization, but to convince people to do the actual work do you have a specific example where you are seeing a performance or other issue due to not being able to inline the VI?

[Intaris]

The thread linked to gives an example of a property ndoe call I cannot inline even though it would technically be feasible.

Practically ALL other sub-VIs in our RT loop are inlined at the moment to squeeze out every last bit of performance.  This VI (and another which reads the corresponding input FIFO) cannot be inlined.

If we can save 0,5 us in our loop time, we're giddy.  For us, this is an issue.  Not a huge issue, but it's an issue.

[kegghead]

It seems ridiculous that I can have an inlined class accessor VI but the property node representation of it can't be. This isn't a deal breaker though, if the consumer of the class is in a tight loop, they can decide to use VI interface instead of property nodes. Of course the fact that the syntax used to call a method affects the speed is rather outrageous...

As for non-class property nodes like your FPGA example, I can't say I have enough experience to say what "should" be done, other than the blind restriction reeks of a lazy implementation to me.

[AristosQueue (NI)]

> Of course the fact that the syntax used to call a method affects the speed is rather outrageous...

I agree. Hard to do anything about it in the short run, but worth keeping in mind as we go forward. I didn't even realize until today that it wasn't inlinable. The data accessor VIs underneath the property node CAN be inlined. It is only the property node caller that cannot.

Although, to be clear, the Property Node isn't exactly the same semantics in the first place. That's no excuse for not being able to inline, but saying the VI call and the property node call are two syntaxes for the same thing isn't exactly true. The error handling behavior of the property node does change the functionality.

[Sam_Sharp]

This is now especially true with Malleable VIs - I would like to create a malleable VI for setting control/indicator properties (e.g. setting visible/enabled state) but it's not possible because the properties cannot be inlined.

I want to use a malleable VI so that it can accept a scalar/array of references, and for the Disabled property to allow a True/False input for Enabled/Disabled & Greyed Out.

[Sam_Sharp]

To be clear, this is the kind of thing I would like to do:I currently have this as a polymorphic VI that I think is a good candidate for a malleable VI.

[Sam_Sharp]

Has this restriction been lifted in a more recent version of LabVIEW? I just tried the above snippet in LV2019 and it looks like it works fine?

[AristosQueue (NI)]

Brand new in LV 2019. Guess we missed marking this idea as complete. 🙂

[Darren]

Available in LabVIEW 2019 and later.