Local Variables and INLINING

[CoastalMaineBird]

LV2013SP1

When making a VI that originates a TYPEDEF'ed cluster, I have always used a local variable of that output cluster, and a BUNDLE BY NAME function to insert the various pieces.

Like this:

 

Now, when I try to INLINE the VI that does this, I get an error message: "This object is not allowed in a VI on which you enable inlining".

I can replace it with a constant easily enough:

My questions are these:

1... Why is the first method illegal?  I suspect something to do with thread-switching into the UI thread, is that it?  Or maybe there really isn't a front panel if it is INLINEd?

2... Is the constant pattern better, in terms of memory usage?

3... Is the constant pattern better, in terms of speed of execution?

4... Should I adopt that pattern anyway, regardless of INLINE or not?

[JÞB]

You are exactly right about the UI Thread being the cause of not being able to inline a local.  inlined code must execute in the callers execution system so no UI thread calls are permited.

In terms of performance the local will cause a data copy the constant might meet the "magic pattern" criterea for the compiler and reuse the same buffer in later versions of LabVIEW.  I would tend to use the constant. 

[nathand]

Local variables don't force a switch to the user interface subsystem; that's why they're better than the property nodes. Local variables also don't require a user interface (for example they work fine on RT targets). So the user interface question isn't relevant. I'm not sure why the compiler doesn't allow it, but it could lead to some ambiguous or poorly-defined behavior (do multiple instances all share the same local variable, or different ones?).

In non-inlined code, the local variable will act like an uninitialized shift register - it will hold the value between iterations. If that is not the behavior you intend then in my opinion the constant is preferable since it expresses the intent more clearly and avoids the risk of getting different behavior between iterations. It might also be more efficient for the compiler.

[CoastalMaineBird]

In terms of performance the local will cause a data copy the constant might meet the "magic pattern" criterea for the compiler and reuse the same buffer in later versions of LabVIEW. 

What is this "magic pattern" you speak of?  Is there a description somewhere?

Thanks,

[CoastalMaineBird]

I'm not sure why the compiler doesn't allow it, but it could lead to some ambiguous or poorly-defined behavior

--- I don't see why the basic behavior should be any different for INLINE than for regular.

(do multiple instances all share the same local variable, or different ones?).

--- Since INLINE requires that it be REENTRANT, I think that question is answered the same as for any REENTRANT vi.

[CoastalMaineBird]

 inlined code must execute in the callers execution system so no UI thread calls are permited.

I don't understand that.  The caller could use a local variable, so I don't see why it would be illegal for the child.

The more I think about it, the more I think it's because the front panel control DOES NOT EXIST if the thing is inlined.

There is no need for it (normally).  It's really only symbolic for the actual data connection, and for a memory chunk reserved for it to hold data.

On an INLINE vi, that indicator hasn't been PLACEd on the caller's panel, so it doesn't really exist.  Therefore the mechanism for it having memory doesn't exist, either.

In my pattern, I didn't need the memory of the last value (since I replaced EVERY element anyway), I just needed something to carry the TYPE, so that I could use BUNDLE BY NAME, rather than just BUNDLE.

That pattern I started using 20+ years ago, looks like it's time to change.

[nathand]

I think I have an explanation. When you inline, all the input and output terminals are replaced by wires. Since the indicator isn't there any more, you can't have a local variable for it.

EDIT: looks like you beat me to posting the same conclusion.

[JÞB]

Magic Pattern

go ahead and benchmark it against an IPE.  the "Magic" is that the cluster can and does operate inplace.  (Smart darn compiler!)  Cost me a point on my last CLD-R since the IPE is faster in 2009 but, I had noticed the performance hit in 2011.  The term "Magic Pattern" was dropped on me while discussing the fine point with the expert's panel only a rew weeks ago at Developer Day.  (By the guy I accused of "probably" writing the optomization--- he denied writing it but, acknowledged he oversaw the developers who did.)

When you are trying to squeeze that extra bit of performance out of your code you may be doing something else wrong.

[JÞB]

Nice point Nathand!  the data copy is cashed for the UI refresh cycle when using a local.  The UI Thread is still tasked.  a very fine point!  the outcome is the same.  locals cannot be inlined.  the exact why is not explained the what is.

[CoastalMaineBird]

 the exact why is not explained

I believe the "why" IS explained. This all makes sense to me now.

There can be no instance of the control/indicator, because it's never been placed on the caller's panel.

If it existed, it would have to have properties like POSITION and BOUNDS, and those have never been set.

They COULD NOT be set, since they would have to be set (differently) for each instance of the inlined VI.

The INLINEd VI requires REENTRANCY, that means there is a separate dataspace for each instance.

I suppose that dataspace now would come from the caller.

The point of the INLINE is to connect the caller's output wire to the VI's input wire AS IF the VI's code were copied into the caller.

That means that the CONTROL/INDICATOR is totally unnecessary, and can be removed.

It therefore cannot be accessed.  Not by property nodes. Not by local vars.

AND, ON A HUNCH, I tested this:  NOT BY REFERENCE.

With a REFERENCE to a control/indicator on an INLINEd VI, I get the same error: this object is not allowed in a VI on which you enabled INLINING.

Because it doesn't exist.

The control/indicator is a metaphor for the interface between the code and the screen display.  It ceases to exist when INLINEd.