LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Better way for inserting column into array?

I have to insert a 2-D array(20x10) into the end (column) of a bigger 2-D array(1000x10). I am seeing two ways to do that:

 

1. Insert smaller 2D array at the end of bigger array.

2. Insert the bigger array at the 0th column of smaller array.

1.png   2.png

 

Which one would be more efficient? Will there be any performance difference?

Or any other better way to do this?

The second one looks simpler but I think it would require a bigger copying of memory.

0 Kudos
Message 1 of 14
(3,417 Views)

I vote for Method 1 Cat Very Happy

 

But you can just use also:

Method 3: the "Build Array" primitive command, which will glue the two together without requiring any additional calculations of indices.

0 Kudos
Message 2 of 14
(3,386 Views)

@ghighuphu wrote:

I vote for Method 1 Cat Very Happy

 

But you can just use also:

Method 3: the "Build Array" primitive command, which will glue the two together without requiring any additional calculations of indices.


Since the OP wants to add columns the Build array would have to be combined with Transpose 2D array on the input and output arrays.

 

0 Kudos
Message 3 of 14
(3,381 Views)

Just use build array with concatente inputs.

 

Make sure the smaller array is the second input. http://www.ni.com/newsletter/51495/en/ Point 6

 

Excerpt:

 

Adding elements to the end of the array is more efficient because LabVIEW has already allocated additional memory beyond the original size to accommodate appending values


CLA CTAChampionI'm attending the GLA Summit!
Subscribe to the Test Automation user group: UK Test Automation Group
Message 4 of 14
(3,374 Views)
  1. For those sizes, I wouldn't bother with any optimizations. Your larger array takes up less than 80 KB of RAM, which is not a lot. It should be fast either way.
  2. I don't feel like looking up the way LV holds 2D arrays in memory, but I believe it's exactly as you'd expect - the first row, then the second, then the third, etc., all in one contiguous block. That means that LV will have to do a lot of moving around anyway.
  3. In principle, both of them could probably be done using the exact same number of calls to move the data around, but I have no idea about the actual implementation - LV might decide to create an entire new block, it might decide to move things in bulk within the current block, etc. In short, the actual behavior is an implmenetation detail and probably subject to things beyond your control and knowledge.
  4. If this is really important, then you might need another way of doing this, but that really depends on the details of your actual situation.

___________________
Try to take over the world!
0 Kudos
Message 5 of 14
(3,367 Views)

Both methods use a buffer allocation, so they might be very similar. Since we don't know what the compiler is doing, you could also try this:

 

 

I am assumung that you only need to append once and not append more and more columns as the program progresses. Is this correct? In any case, you should consider operating on the transposed version, because it is always easier to append rows instead of columns (rows are adjacent in memory, while appending columns require more data shuffling under the hood

 

In any case, you should simply wire up the alternatives and do a proper benchmark if you are planning to use this on much larger arrays in the future, for example. Can you give us some context how you are planning to use this?

0 Kudos
Message 6 of 14
(3,359 Views)

@altenbach wrote:

Both methods use a buffer allocation, so they might be very similar. Since we don't know what the compiler is doing, you could also try this:

 

 

I am assumung that you only need to append once and not append more and more columns as the program progresses. Is this correct? In any case, you should consider operating on the transposed version, because it is always easier to append rows instead of columns (rows are adjacent in memory, while appending columns require more data shuffling under the hood

 

In any case, you should simply wire up the alternatives and do a proper benchmark if you are planning to use this on much larger arrays in the future, for example. Can you give us some context how you are planning to use this?


With the given dimensions you should transpose the arrays before and after the for loop... you would only get a 20x20 array as output.

On the other side the OP said he wanted to add columns... that means that the arrays have wrong dimensions.

0 Kudos
Message 7 of 14
(3,351 Views)

OK, here you go, see attachment (known bug: You have to unlatch the OK button after each stop.). Benchmark it for your self on your system.

 

I get very alternating results. None of them is super-perfect all the time.

 

Cheers,

 

 

0 Kudos
Message 8 of 14
(3,343 Views)

@dan_u wrote:

With the given dimensions you should transpose the arrays before and after the for loop... you would only get a 20x20 array as output.

On the other side the OP said he wanted to add columns... that means that the arrays have wrong dimensions.


Have you even tried it and compared with version 1 and 2 from the original post? All give the same result.

 

The two input array have the same number of rows, so the output array will maintain the same number of rows but will have as many columns as the sum of the columns of the two input arrays.

 

Please check again. (True, the poster did not specify of the first dimension means rows or columns, but from the code we can deduce it)

0 Kudos
Message 9 of 14
(3,341 Views)

@ghighuphu wrote:

OK, here you go, see attachment (known bug: You have to unlatch the OK button after each stop.). Benchmark it for your self on your system.


This is a really bad benchmark and the results are pretty meningless because all three code alternatives run in parallel, fighting for the CPU. Whats up with the value property nodes? Why is debugging enabled? What do you think will happen on my dual-core laptop?

 

Your triple-transpose shows the largest number of buffer allocations.

0 Kudos
Message 10 of 14
(3,329 Views)