In place element structure - Please explain

[Muri777]

Hey guys,

I understand how in place elements are good for DVRs, but I would like more information on when to use it. More specifically, on how to know when to use it. From this link (https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/in_place_element/) its explained that it has the potential to stop copying data when not needed. However when I run the "Show buffer allocations" tool from within Labview, I cant seem to see how the example works. Its hard to see so I have circled the black spots which indicate an allocated memory buffer, but I cant see how using the IPES is any better? Maybe I have done something wrong. Please see image below (copied straight from the example). Is the only difference the missing allocation on the increment? I am assuming there should be one on the integer on the top pic too, but it isnt appearing and I dont know why.

Thanks heaps

[Konan__]

You want to use it when you loop with high speed on that operation.

If you just do the operation 1 time , it's useless.

If you use the operation 100 times, it's useless.

From 1000 onwards it will speed up your software execution. In your case specifically, expecially if the array is big (from 1000k elements onwards)

[altenbach]

(the above answer makes absolutely no sense).

---

@Muri777 wrote:

...its explained that it has the potential to stop copying data when not needed. However when I run the "Show buffer allocations" tool from within Labview,

---

The IPES has fewer primitives, fewer wires, and is easier to read. That's about it in terms of "advantage", but these are desirable features! First of all, both code examples are basically identical. The compiler is smart enough to ignore the array wire branch and "replace array subset" operates in place too. The compiler is smart enough to create equally efficient code for both cases. While there is a buffer allocation for the scalar, it's nothing compared to the array and that tiny allocation will be re-used for all future iterations, so it is basically free.

I agree they probably should come up with a better example.

[crossrulz]

---

@altenbach wrote:

First of all, both code examples are basically identical. The compiler is smart enough to ignore the array wire branch and "replace array subset" operates in place too. The compiler is smart enough to create equally efficient code for both cases.

---

It is usually pointed at the Unbundle By Name - Bundle By Name combination, but what we have here is the "magic pattern", which NI figured out about 2 years after the In Place Element Structure was released.

I also prefer using the In Place Element Structure because it seems cleaner.  The compiler doesn't care any more.

[billko]

---

@crossrulz wrote:

---

@altenbach wrote:

First of all, both code examples are basically identical. The compiler is smart enough to ignore the array wire branch and "replace array subset" operates in place too. The compiler is smart enough to create equally efficient code for both cases.

---

It is usually pointed at the Unbundle By Name - Bundle By Name combination, but what we have here is the "magic pattern", which NI figured out about 2 years after the In Place Element Structure was released.

I also prefer using the In Place Element Structure because it seems cleaner.  The compiler doesn't care any more.

---

I've never considered this seriously until just a couple of weeks ago, I saw someone who used them just about everywhere, and I said, "Now how nice and organized that looks!" and I think this is going to become part of my coding practices.

[Muri777]

So besides it being cleaner to look at, I shoudlnt try using them?

I dont have arrays that have 100k elements, but I do have software that runs at 20ms on RT and 1ms on FPGA. Are there any other advantages? 

Thanks heaps

[rolfk]

The question could be also turned around: Should you NOT use it and the answer to that is actually no!

Should you use it? Yes why not but if you don't you won't generally have any problem since the LabVIEW compiler is usually smart enough to recognize this pattern and generate equivalent code even if you don't use the IPE.

But!!!! When you do not use the IPE, you could accidentally add extra code to the diagram that prevents the compiler to do this optimization. With the IPE you will generally not be able to add such code without causing bad wires, so it is in fact more safe.

[RamonG]

I had a (edge) case that was less favorable using the IPE structure compared to without. If you want to optimize performance it might be useful to check both solutions.

[altenbach]

---

@RamonG wrote:

I had a (edge) case that was less favorable using the IPE structure compared to without. If you want to optimize performance it might be useful to check both solutions.

---

That's not an edge case, but incorrect usage. First of all, prepending elements to an existing array is significantly less efficient than appending. By definition changing the size of arrays cannot be done "in place" anyway. Once you have more information about the problem, I am sure your "algorithm" could be significantly more optimized. Any code that contains a "request deallocation" is highly suspicious anyway. in 99% of cases, it makes things worse.

[RamonG]

---

@altenbach wrote:

---

@RamonG wrote:

I had a (edge) case that was less favorable using the IPE structure compared to without. If you want to optimize performance it might be useful to check both solutions.

---

That's not an edge case, but incorrect usage. First of all, prepending elements to an existing array is significantly less efficient than appending. By definition changing the size of arrays cannot be done "in place" anyway. Once you have more information about the problem, I am sure your "algorithm" could be significantly more optimized. Any code that contains a "request deallocation" is highly suspicious anyway. in 99% of cases, it makes things worse.

---

I know it was the wrong approach, it's one of those things you know you need to revisit but don't because there's never time to do so. My point was to warn against using primitives that you don't fully understand, just like I did.