LabVIEW
Processing Time and Memory Usage
Solved!
This is not scientific, but I usually play the game of "Whack the dots". (Note the dots are possible memory allocations BUT may not be a memory allocation in reality.)
The alternative shows two dots, a dot for the original array and a dot for the scaled array, for possible memory allocations.
Your for loop definitely makes an additional copy, so the results will probably be similar.
@mcduff wrote:
This is not scientific, but I usually play the game of "Whack the dots". (Note the dots are possible memory allocations BUT may not be a memory allocation in reality.)
The alternative shows two dots, a dot for the original array and a dot for the scaled array, for possible memory allocations.
Your for loop definitely makes an additional copy, so the results will probably be similar.
I agree! Since none of the basic math is needed inside the For Loop, operating with a Scalar on the Loop Array output would optomize the code. With debugging disabled, the compiler will migrate the loop output and use the Loop constant inputs to act upon the array elements "In Place"
With debugging enabled, it is a gross mistake to perform the math on each element! The math should be left outside of the loop!
Once debugging is disabled and the compiler applies all optimizations, the binary code with be similar.
With debugging enabled, extra code needs to be inserted so you can "probe" the wires inside the FOR loop, which prevents certain optimizations.
Your FOR loop code is just plain silly. The more reasonable way would be to autoindex at the output tunnel. The compiler knows exactly what the final size will be and will do the allocation for you already. Doing all that explicitly (getting the array size + initialize the array + reading the index + replacing the elements) just dramatically complicates the diagram. If you keep doing that, your code will be twice the size it needs to be, harder to debug, and will have twice as many places for bugs to hide! 😄
Read more about the compiler here.
The correct way is the flat, no-loop code. It also has a greater chance to utilize SIMD instructions. There is a chance that the compiler will recognize your "code pattern" and do that anyway.
@Thom77724 wrote:
I am scaling an array of raw data values. Currently I pre-allocate an array to place the scaled values in using append array element, in a for loop (show in the attached image). I have also attached an image of an alternate method of doing this purely using multiply and add on the array. My question... Which runs faster? which uses less memory?
Memory use and speed are irrelevant for tasks like this. No need to go on a witch hunt! The compiler knows what to do, All you need to do is keep the code as clean, simple, and readable. In your pictures, most of the memory is used by the array control and indicators here (they have their own memory and transfer buffer)!
If you have performance problems, you are currently looking in the wrong place! They will be elsewhere!
@JÞB wrote:
@CA
Didn't I just say that? With less memory allocations!
I am sure we are trying to say similar things, but if I search this entire thread for the word "memory", none of your posts contain it, (except this one and from quoted content from others).
If the data needs to be scaled, it needs to be scaled and where that should happen depends on the overall architecture. The compiler knows at which wire branch the memory can re re-used or where a copy needs to be made instead. I've had scenarios where forcing a copy by inserting an "always copy" actually greatly improved performance.
True raw measurement data is typically integers based on the number of bits in the converter. If we already have the data as DBL, it means some scaling already happened upstream and we are just repeating it with different factors. Done right, once would have been sufficient!
Also, if this is just for display on a graph, we could change y0 and dy of the axis, leaving the array data untouched.
Still, worrying about memory use for such a simple task is barking up the wrong tree. Any performance/memory problems will be elsewhere.(even with debugging enabled!)
