LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Inlineable property nodes / Invoke nodes when apporopriate

Status: Completed

Available in LabVIEW 2019 and later.

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.

9 Comments
Active Participant

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?

Proven Zealot

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.

Member

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.

Proven Zealot

> 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.

 

 

Trusted Enthusiast

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.

Trusted Enthusiast

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

Trusted Enthusiast

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?

Proven Zealot

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

Proven Zealot
Status changed to: Completed

Available in LabVIEW 2019 and later.

DNatt, NI