Buffer Function as efficient as the Waveform Chart's

[Aaron_KZ]

The waveform chart has an awesome low level buffer built-in.  I wish I had a simple drag/drop buffer function/subVI that was as effiecient. 

The attached zip contains some buffer comparisons that I was messing with when I thought how nice it would be to have an efficient XY Chart:

  https://forums.ni.com/t5/LabVIEW-Idea-Exchange/XY-chart/idi-p/2045138 

It got me thinking about how nice it would be to have a buffer as good as the one inside the waveform chart.

With minor modifications to the attached comparisons, you can easily see how the chart is SO MUCH more efficient as a buffer than any I made or found. You can take out the graphs, and the chart will finish updating its buffer AND drawing its new plots before the others can even finish updating their buffers!

[Darin.K]

That super-duper buffer would is commonly referred to as a circular buffer.  See here:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-1D-data-container-Circular-Buffer/idi-p/2268586

[altenbach]

There is the collector express VI and the data queue ptbypt function.

(EDIT: Just looking at your code, all your sequences on the right run in parallel, stealing each others CPU cycles. Your benchmark is completely meaningless.)

[Aaron_KZ]

Darin,

I implemented many circular buffers in the comparisons (see attached code for the various ways in which I accomplished circular buffers)

[crossrulz]

Along with your benchmarking being in parallel which invalidates them, what is your goal?  For each of these methods, you are making copies to display the data EACH ITERATION OF THE FOR LOOP.  This invalidates your benchmarking.  If all you need is a circular buffer, not displaying, then I found the lossy queue to be faster (~20X).

[Aaron_KZ]

Interesting, as it is the slowest example in the attached code by a HUGE margin

[crossrulz]

Again, that's because you are making a lot of copies of the massive array to display it.  If you are just saving data in a circular buffer and only need to read it off once when an event happens, the lossy queue is the way to go.  When I removed all of the display code in the FOR and waits in case structures (more stuff to invalidate your benchmarks) in the FOR loops, I got the lossy queue in at 0.244 sec, the waveform chart at 1.964 sec.  There were other conciderable speedups by removing the constant display updates.

EDIT:  I went ahead and removed all of the other algorithms from the VI as well and got the lossy queue at 0.088 sec and the chart at 1.314 sec.

Again, these are not true valid benchmarks since they are running in parallel.

[Aaron_KZ]

Wow...  I didn't mean to get so many people upset...

So, maybe I should specify that I would like to have a better buffer that plays nice with XY graphs whiloe inside a loop 

OK, I put the threads in parallel, but left the XY graphs in the FOR loops.  The call VI by ref did best with the XY graph in the loop.  cool, but the lossy was still way worse:

then I left the sequential execution, but deleted the graphs all together, and you were very correct.  The lossy Q blew their doors off when nothing else is going on...

[altenbach]

I think this benchmark and code design discussion should be moved to the LabVIEW forum. It does not belong in the ideas exchange.

[crossrulz]

---

Crazy_KC wrote:

So, maybe I should specify that I would like to have a better buffer that plays nice with XY graphs whiloe inside a loop 

---

Sounds like you just want an XY Chart (another one of your ideas).

[SteenSchmidt]

@Crazy_KC: Maybe the GPower VIRegister toolset will serve you until something native turns up?:

In case it does just drop me a message. The version on the LabVIEW Tools Network is way out of date.

The toolset is built around queues internally, so performance is probably as high as it's gonna get in LabVIEW currently.

Cheers,

Steen