LabVIEW
How can I make intertwined loops faster and increase the limit of used labview memory
Solved!
Can you do a "save for previous, LabVIEW 2020 or below)?
(I currently don't have access to LabVIEW 2023 until later)
Do you really have 4D arrays? What's the datatype?
Can you explain what the data represents, where it comes from, and what algorithm you are trying to implement?
Only two of your inputs are on the connector pane (Z, Z2), so where does all the other data comes from?
A 4D array of 101x261X261X64 DBLs already needs several contiguous GB in memory for one data copy you'll never will be able to run it in 32bit LabVIEW. Do the math! Even if you would use SGL, you'll run out of memory!
What's the purpose of the sequence structure? Why do you need that extra loop stack on the left? Why not average the nonzero elements in the main loop.
Why would you hide labels of terminals? A really bad habit! Just to obfuscate the code?
There is no reason in the world to maximize the front panel and diagram to the screen. Another bad habit!
As has been said, there is a fundamental barrier to even run this on 32bit LabVIEW with the full dataset. (And I doubt it is reasonable even on 64bit!)
Here's your code slightly cleaned up so we can actually debug it. This is a literal verbatim rewrite without any attempt at optimization. I see many places to optimize!
In terms of performance, Deep stacks of loops have a relatively large debugging overhead. Your code doubles in speed if debugging is disabled and the outer loop can be parallelize for a speed increase proportional to the number of CPU cores if you remove the incremental timing. (still does not solve your memory problem)
With the 11x27x27x64 4D DBL array of your example and using all default data, the code executes in about 100ms here.
Your 4D array data seems very smooth and maybe does not even need to exist in memory, but could be calculated from simple math based on the array indices.
You are confusing us with piles and piles of FOR loops that creates a 4D array with a huge redundancy in the elements.
Maybe you could explain the math behind it instead!
You seem to create three linear ramps which you transform into a gigantic hairball of a 4D (!) array. Can you point to a manual or website that explains the processing of the blue input array based on these three ramps? I get the feeling that this problem is much simpler than you want us to believe. 😄
@Yakup1971 wrote:
Thanks for your replies;
Please never ever attach a new VI with exactly the same file name as an older VI. Very confusing to keep things organized.
@altenbach wrote:
Maybe you could explain the math behind it instead!
Still waiting for that!
As a small example, here's how your lower left loop could be simplified (but that's not your bottleneck)
Since all your calculations are in DBL, you should covert it to DBL as first step, of course. Fortunately, your inpt data is all positive, else the Sum!=0 is problematic, because e.g. [-5, -2, 0, +5, +2] would sum to zero, even though the data is valid.
