In Place Elements without the box

[dj3]

I use a lot of clusters in some apps and using the in place element box can make the diagrams significantly larger and a bit unwieldy if you need to do some complex calculations. My idea is this:

right click on the increment icon:

Click on "Inline":

The box indicates that it is an inline operation so we also don't need to define the receiving cluster as labview knows that it is the same as the source cluster. The receiving cluster can now be placed where it is most convenient rather than being tied to the in place element box.

[dj3]

Whoop, that was supposed to read InPlace not Inline. (I was in a hurry as I sneaked it in while at work 😉

[soupy]

You should come to terms with the fact that physical block diagram space is not coupled with code performance. use the inplace element structure and move on with your day.

[Brian_Powell]

Interesting.  Before we had the inplace element structure, we tried to detect this thing we called "the magic pattern".  It was essentially the diagram you show at the top.  If we detected the magic pattern, we would make the clusters inplace and try to force whatever was between them to be inplace in the right way so that no copies were made.

But, given that there can be arbitrary amounts of other things on the diagram that's wired to this, it was sometimes difficult to detect the magic pattern.  And then we had this great idea--what if we had the user use a box to encapsulate the code that should be in place?  We could call it the inplace element structure, and have the user show us instead of having to always guess.

Thus ends the history lesson.

The good news is that we still have code that tries to detect the magic pattern; it's just not as critical now that we have the IPE structure.

I think you could either consider this idea implemented (minus the popup menu item on functions) or rejected.

[dthor]

Brian,

Are you saying that, for the code in dj3's example, that compiler is smart enough to recognize that the code can be acted on-in place, and thus does so? In a similar fashion to constant folding or dead code removal: the compiler sees the potential for optimization and then runs the optimized code at runtime or when an executable is built.

[drjdpowell]

>Are you saying that, for the code in dj3's example, that compiler is smart enough to recognize that the code can be acted >on-in place, and thus does so? 

Yes.  

The advantages of the IPE struncture are less doing things in place, as being sure that things are done in place.   In complex code, it can be easy to have a situation where you think the compiler is doing it in place, but it isn't because of some detail of how you coded it.  Using the IPE forces you to code in the way that is always optimizable.

[dj3]

Thanks, that's good to know. It's not always obvious what's happening under the hood.

[Darren]

Any idea that has received less than 7 kudos within 7 years after posting will be automatically declined.