@proland1121 wrote:
from 2009... http://digital.ni.com/public.nsf/allkb/F3FB3A32B51BF33E8625763100704136
Additionally, the Build array function carries out a memory copy operation, which can slow you down.
Excerpt from: http://zone.ni.com/reference/en-XX/help/371361H-01/lvconcepts/vi_memory_usage/
"If the size of an output is different from the size of an input, the output does not reuse the input data buffer. This is the case for functions such as Build Array, Concatenate Strings, and Array Subset, which increase or decrease the size of an array or string. When working with arrays and strings, avoid constantly using these functions, because your program uses more data memory and executes more slowly because it is constantly copying data"
Basically, each build array operation attempts to first copy the data from one space in memory to another. This is the step vulnerable to "out of memory error". I may be wrong about it needing to be contiguous in regards to this error.
Just to clarify that one point.
The Build array MAY do a memory copy. LV is pretty smart with managing memory and will attempt to avoid the costly memory allocation if it can. The numbers may have changed since I was studying this operation but at an early date (about LV 6.1) LV would allocate maybe 1K to an array in a SR to start. It would keep filling in that memory until it ran out and then when it out-grew the allocation, would allocate a buffer twice as large. move the old data to the new buffer and then start working in that contiguous memory space. each time a "malloc" was required, the buffer doubled in size.
modern version of LV have a;
Tools >>> Profile >>>> Profile Buffer Allocations
That will let you monitor the buffers.
Now I am going to repeat myself from above.
Multiple queues can be used as buffers and the various queues do not require contiguous memory. They operate "in-place" so transferring an update from DAQ to display requires only moving handle from one thread to another and the data can sit just where it was when it was queued up.
Now if you still want to read more, check the links in this Tag Cloud for LabVIEW_Performance. Included in that collection are post from Greg McKaskle who (when last I checked) was a Chief Architect for LabVIEW and used to answer questions here in this forum... right up to when LV 7.0 was scheduled to be released and management had him concentrate on developing instead of supporting.
Ben
