Not enough memory error when passing an array to a chart

[Yamaeda]

And with 24k elements, is it 2 mins? Drawing takes time, your enqueue uses basically 0 time. When drawing you'll fill up the queue.

/Y

[AndyN]

I only redraw it 2/s. Since I flush it on every call I also clear the buffer.

On the update note. I just implemented a graph with my own history buffer of 2000 points (just one plot).

It does not have any memory issues. I ran it for good 10 min.

However the task manager now shows memory allocation for LV about 200 MB instead of 3GB....?

There is something fundamentally wrong with the way LV allocates memory for the charts or the way I pass elements to it.

[Yamaeda]

Then it sounds like every queue reserves 240k elements worth of memory and after flush reserves a new chunk.

[AndyN]

 No it doesn't sound at all. I don't think queues work like that....The memory is allocated once outside of the loop  during queue creation. Have you looked at the code at all?

Every flush takes about 100elements off the queue. Checked.

[AndyN]

Here is a simple 1 plot  implementation with a graph. It does the same thing as the chart except it does not crash.

[crossrulz]

The chart implements a circular buffer inside of it.  So each time you write, data has to be moved around.  This can cause some slow downs.  The chart just displays the last thing you wrote to it.  So it does make sense that the graph will use less memory.

But your other memory hog is copying the data out of the queue.  I still don't see the point in this separate loop.  Just use a chart in the main loop (where you are enqueuing).

[AndyN]

Thanks.

I though it does use a circular buffer.

What I did for the graph - I wrote my own circular buffer. I can set the size of it as well.

It has the same functionality as the chart which makes me wonder why the chart fails. So the graph with 2k buffer flies through the data and the chart with 1024 fails on the first call.

It also makes me wonder why it needs to move the data? Can it just ( the implementation) move the pointers? 

Which is more CPU memory extensive: copying 20kB once or copying 20 k times one Byte ( plus 20k calls to dequeue)?  I am asking seriously.

The enqueueing loop reads the input at 200Hz with a future possibility of 1000Hz. For that reason I do not want to see any printing or local variables or blocking functions in the producer loop.