LabVIEW
build array out of memory
There is nothing that should run out of memory. Does the problem really occur with the "simplified" example you have attached?
What makes you think it runs out of memory at the "build array"?
If you dramatically speed up the loop (e.g. remove all waits), you will obviously run out of memory in the queue because you generate numbers much faster than they can be written to disk. You need to ensure that the generation rate is less than the average maintainable speed of the disk IO.
Using write to spreadsheet file is also a low performance option, because of the constant file open/close operations and all the formatting steps. If speed matters, use a binary file and low level file IO. Open it once before the loop, and just append inside the loop. Close it when the loop ends.
Maybe you should set an upper size limit for the queue?
I don't have the ogtk subVI, but here's how your code could be simplified (not showing the file IO suggestions). The browse option for the file controls also should be "new or existing".
@brian19876 wrote:
is using build array in a loop a bad idea does it cause memory leaks
That depends.
Your array is fixed size and there is absolutely no problem. It is allocated at compile time and never changes.
(Problems occur e.g. of you use bult array in a loop to grow an array without limits e.g. in a shift register)
As Altenbach stated, your problem is that your consumer loop is way too slow. File I/O just tends to be slow anyways. But the Write To Spreadsheet File is REALLY slow due to the opening and closing of the file. Open the file before your loop and close it afterwards. You'll be amazed how much this will speed up that loop.
And since you probably don't want to be losing data. do NOT stop the consumer loop with the error by releasing the queue once the producer loop is complete. Instead, send something like an empty array after the producer loop. In your consumer, check to see if you got the empty array (there is a really simple function in the comparison palette to do that for you). That will be the notice for that loop to stop. Release the queue when the consumer loop is complete.
@crossrulz wrote:
Instead, send something like an empty array after the producer loop.
(sorry, I put that in there for simplicity. The original code had independent stop buttons, one for each loop, and killing loop 2 without also stopping loop 1 would definitely result in an out of memory situation. 🐵
Alternative to your suggestion (maybe an empty array is sometimes a valid element! 😉 (not here, but in general)) You can also check the queue size in a slow loop after the producer loop and only kill the queue once it is empty.
altenbach wrote: You can also check the queue size in a slow loop after the producer loop and only kill the queue once it is empty.
We may have just opened up a Holy War. I will just say that stopping a consumer loop based on an empty queue is a really bad idea unless you are VERY careful. In general, you should stop the consumer loop based on a command coming from the producer through the queue. The format of that command is often debated.
