Inefficiency in Waveform Generation VIs

[mcduff]

---

---

@hieyequeue, @bobschor

---

Downloaded both your tests and got the same results you did. In Bob's version swap was faster, in hieyequeue's version build was faster.

I think I know why hieyequeue's version is slower for swap, look at the buffer allocations.

In hieyequeue's version there is a buffer copy for the swap, in Bob's version there is no buffer copy for the swap. So in hieyequeue's version not only are you swapping but you are make a buffer copy which slows down your benchmark; the build in hieyequeue's version does not make a buffer copy.

Not sure why there are differences in copying buffers between the two versions, but I think it explains the different results.

mcduff

[hieyequeue]

Hi mcduff,

I added the indicators as you suggested.  I found the build loop to be 25% faster.

[mcduff]

See message 11; I think your benchmark creates a buffer copy where Bob's does not.

mcduff

[oscarfonseca · Accepted solution]

Hello all,

We use the Swap Values function because it is more efficient than moving the new waveform data into memory. As the help says: Places the value of the y input into the x' output and the value of the x input into the y' output without allocating memory to perform the operation. Tl,dr: We swap the reference to the array, not the array itself (therefore avoiding a memory copy).

This way, the waveform cluster is commanded to get its array data from the new array in memory (without having to copy the new array into the location where the cluster was storing its old data). LabVIEW will eventually deallocate the unused one when it's the best time to do so.

Now, for LabVIEW 2019 the team worked to make cluster insertions 'smarter' and now this method is the preferred one for the compiler to use. Therefore, if you are doing your benchmarks with LabVIEW 2019, I would expect them to be similar in times since both should be using the same underlying method to insert the new value to the waveform cluster.

I hope this helps clarify the reasoning behind this code decision.

All the best,

[mcduff]

---

@oscarfonseca wrote:

---

Related question: Since the compiler optimizations are changing what is the best way to code? For example, swap was better in versions <=2018, but now it is worse according to your reply.

I am not crazy about the fact that when we update versions, performance that was previously optimized may now be worse.

mcduff

[hieyequeue]

mcduff,

How so I see or toggle the buffer copy?   FYI, I just cut and pasted what I found in the Waveform Generation VIs.

[mcduff]

Choose array after you click show buffer allocations.

mcduff

[oscarfonseca]

mcduff,

I would not expect it to be worse, but to be very similar (the Operating System still will schedule things as it pleases, so it's normal to see those small variations). You should be able to continue programming normally 

Thanks,

[hieyequeue]

mcduff,

Thanks. Nifty tool. Now how do I turn off the buffer copy.

[mcduff]

---

@hieyequeue wrote:

mcduff,

Thanks. Nifty tool. Now how do I turn off the buffer copy.

---

That is one of the great unsolved mysteries of the universe.

The compiler decides when to make a copy. Look at Bob's code, there is no copy; not sure why.

mcduff