Inplace Structure Array Size Management

[Norm Kirchner]

Something that I thought would be a simple act of making some code better has spawned into something very unexpected.

It started with this

and I realized that there was a new buffer acquisition and went wtf?

So I started to think, how can I prevent this allocation?....In-place structure!!!

But all is not as simple as I had hoped. Must be fully reverse compatible/compliant NO EXCEPTIONS.

The reason this falls short is that

w/out the in-place structure, if the arrays are 2 different sizes, the output sizes up and pads zeroes

w/ the in-place structure, the result array size is cropped to the size of the Waveform 1 array size

(not the same functionality)

So now it's necessary to determine who is bigger and then let that one be the element that is 'in-place' operated on.

And now we even need a memory swap function, that unfortunately shows memory allocation as well (but I'll ignore that for now)

But now we're showing buffer allocations on the output of the bundle by name!!! Crap.

Ok, so now I put the inplace structure around my array size logic.

So {aside from the allocation at the memory swap} I think I have the most efficient coding of this very simple VI....which is now not simple.

So would any of you, if you put on the hat of memory efficiency, choose to do this any other way?

Going to be testing speed and memory now.

Download File:post-208-1232497642.vi

So the last step is

[ragglefrock]

I think you're thinking too hard about this.

First of all, the Inplace Element Structure doesn't produce different behavior for a Subtract Node inside it than if you just used unbundles and bundles. By that I mean it doesn't affect the zero padding at all.

Try taking your original example with the plain Unbundle/Bundle nodes and replace them with the Bundle By Name and Unbundle by Name nodes. Voila, your buffer allocation is gone. Or you can simply keep the plain bundle nodes and wire your two scalar values across and the buffer allocation will disappear again. I realize this doesn't produce a different functional result, but for whatever reason it helps LV analyze the inplaceness of the diagram

The best way to make sure the Waveform being modified doesn't have its array resized by doing the subtraction would be to manually loop through its elements in a for loop, which is certainly less efficient than using the Subtract Node's built-in behavior.

[Norm Kirchner]

Just edited my post to make the fact that I was wrong about the zero pad.

But as the edit states, there still is a memory resize which for the sake of argument we want to get rid of at all costs

[ragglefrock]

QUOTE (Norm Kirchner @ Jan 20 2009, 07:56 PM)

For tonight though I will give it a rest and then figure out if you can avoid the memory resize w/out any in-place structures needed

You definitely can. See my last pic with the for loop. In this case the Inplace Element Structure is doing absolutely nothing different than just using Bundle and Unbundle by Name. And it's definitely not faster to use plain bundles than the By Name counterpart. The LV compiler figures out at edit time exactly which operations to perform in each case. There's no run-time penalty. The only possible way in which one could take more time than the other is if you used a Bundle by Name and overwrote the same field twice in one bundle, which there's no good reason to do.

[Peeker]

QUOTE (Norm Kirchner @ Jan 21 2009, 02:03 AM)

Ok, so now I put the inplace structure around my array size logic.

http://lavag.org/old_files/monthly_01_2009/post-208-1232497430.png' target="_blank">

Just a reflection:

There is no need to perform Bundle by name on Y at your array size logic. Y is already in the cluster and has not been changed, so this bit could be skipped, hence no memory allocation there.

//Martin