Jump to content

No Controls/Indicators inside structures...


Recommended Posts

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.

Link to comment

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

Link to comment

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.

post-1037-1216192355.png?width=400

post-1037-1216192366.png?width=400

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 :)

Link to comment

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.

post-1037-1216192355.png?width=400

post-1037-1216192366.png?width=400

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

Link to comment

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.

post-1037-1216192355.png?width=400

post-1037-1216192366.png?width=400

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

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.