No Controls/Indicators inside structures...

[Götz Becker]

Hi all,

does the "No Controls/Indicators inside structures!"-rule also applies for the inplace structure?

[Antoine Chalons]

QUOTE (Götz Becker @ Jul 15 2008, 11:13 AM)

Hi all,

does the "No Controls/Indicators inside structures!"-rule also applies for the inplace structure?

Hi,

Why such a question ?

I think it's more readable when controls/indicators are outside structures. I think the rule applie for case structure but not for loops, sometines you have no other choice than putting controls/indicators inside of a loop.

As regards inplace structure... I would put a control/indicator into it but this feeling is not based on a proper deduction.

Maybe it's interesting to put a link to http://forums.ni.com/ni/board/message?board.id=170&message.id=191622' target="_blank">this thread on NI Forums.

[Götz Becker]

I just had a usecase in which I needed to update a nested element of a large structure. This involved 4 inplace (unbundle, array index, variant, unbundle) structures to get to the point where I needed the data from the control. The placement "felt right" in there... I just was curious about how "good" this would be.

[LAVA 1.0 Content]

QUOTE (Götz Becker @ Jul 15 2008, 08:20 AM)

I just had a usecase in which I needed to update a nested element of a large structure. This involved 4 inplace (unbundle, array index, variant, unbundle) structures to get to the point where I needed the data from the control. The placement "felt right" in there... I just was curious about how "good" this would be.

As I understand the thread cited by Antoine, that advice applies to sub-VIs and is of importance to help LV optimize the passing of data to and from the sub-VI call.

If the VI is a GUI element and you need to get the control value while in the loop, then that is were it has to be. But if the control is static while the loop is running, then I BELIEVE its better to read the value once before the loop starts and just deal with the value as if its a constant inside the loop.

Ben

[Götz Becker]

I guess I didn´t take enough time to write me question in the first place. First my in case I doesn´t use indicators inside structures, just a control.

I am just not sure if and why LV would optimize the lower solution better. It´s not that important just something I wondered about

[LAVA 1.0 Content]

QUOTE (Götz Becker @ Jul 16 2008, 03:20 AM)

I guess I didn´t take enough time to write me question in the first place. First my in case I doesn´t use indicators inside structures, just a control.

I am just not sure if and why LV would optimize the lower solution better. It´s not that important just something I wondered about

The inplace structures are new enough that I can't speak specifically about them but as I undersand this code guide-line intent...

When LV has decide how it has to pass data to a sub-VI it first tries to do it as effciently as possible. Since copying data (particular large arrays) is time consuming, it tries to avoid doing so. It can avoid copying the data if the data is not modified in the sub-VI. But how does it know if the sub-VI modifies the data? The sub-VI itself can let a caller know it is not going to mod the data. THis condition is possible if the controls indicator that are on the icon connector are located on the root of the block diagram.

I look at it this way. The caller can look into the sub-VI only as far as the root of the diagram. If it can see the data will not be modified, it only passes a ref to the buffer holding the data in the calling VI.

If you run your two VI examples through the same benchmark test I post in the thread on the NI forum, you MAY be able to see a slight differnce in the two methods.

Ben

[Tim_S]

QUOTE (Götz Becker @ Jul 16 2008, 03:20 AM)

I guess I didn´t take enough time to write me question in the first place. First my in case I doesn´t use indicators inside structures, just a control.

I am just not sure if and why LV would optimize the lower solution better. It´s not that important just something I wondered about

My understanding is that reading a control or setting an indicator switches to the UI thread. I would guess that the lower is more optimized because all of the controls are read at the same time, thus only requiring a switch to the UI thread once.

Tim

[Antoine Chalons]

QUOTE (Tim_S @ Jul 16 2008, 02:05 PM)

My understanding is that reading a control or setting an indicator switches to the UI thread. I would guess that the lower is more optimized because all of the controls are read at the same time, thus only requiring a switch to the UI thread once.

Tim

I agree with that, in my understanding, at best the upper case (with the control inside the inplace structure) is as good as the lower case but it might be less good. So if I'm correct the choice is easy to make.

[LAVA 1.0 Content]

QUOTE (Tim_S @ Jul 16 2008, 08:05 AM)

My understanding is that reading a control or setting an indicator switches to the UI thread. ...

Tim

I used to think the same but reading and writting controls and indicator do NOT require a switch to the UI thread. I can't quickly cite proof but I beleive CRELF was involved in the thread were this was settled once and for all (well maybe not all).

CRELF,

Do you remember the thread?

Ben

[silmaril]

QUOTE (neB @ Jul 16 2008, 02:58 PM)

I used to think the same but reading and writting controls and indicator do NOT require a switch to the UI thread.

I think you are right. Why should a simple read from an address in memory make a thread switch necessary?

(But you will definetely have a switch to the UI thread, if you use property nodes.)

[crelf]

QUOTE (neB @ Jul 16 2008, 08:58 AM)

I used to think the same but reading and writting controls and indicator do NOT require a switch to the UI thread. I can't quickly cite proof but I beleive CRELF was involved in the thread were this was settled once and for all (well maybe not all). CRELF, Do you remember the thread?

I do, but I can't find it. I don't think we ever got a definitive answer on that one. I know that it started because we were talking about global varibale usage and how the global data used to reside in the UI requiring a thread swap on reads and writes (it doesn't anymore), and then we started talking about controls/indicators, but I'm not sure if that required a swap. Intuatively, I think it would, but the LabVIEW team have done all sorts of tricks to manage memory and speed, so I wouldn't be suprized if there's a "on change" optimization there. Anyone from NI care to comment?

[LAVA 1.0 Content]

QUOTE (crelf @ Jul 16 2008, 12:46 PM)

I do, but I can't find it. I don't think we ever got a definitive answer on that one. I know that it started because we were talking about global varibale usage and how the global data used to reside in the UI requiring a thread swap on reads and writes (it doesn't anymore), and then we started talking about controls/indicators, but I'm not sure if that required a swap. Intuatively, I think it would, but the LabVIEW team have done all sorts of tricks to manage memory and speed, so I wouldn't be suprized if there's a "on change" optimization there. Anyone from NI care to comment?

I think http://forums.ni.com/ni/board/message?board.id=170&thread.id=175255&view=by_date_ascending&page=1' target="_blank">this was the thread.

Ben

[crelf]

QUOTE (neB @ Jul 16 2008, 12:54 PM)

I think http://forums.ni.com/ni/board/message?board.id=170&thread.id=175255&view=by_date_ascending&page=1' target="_blank">this was the thread.

That wasn't the one I was thinking about, but I think it's just as good (if not, better ).