how to speed up Labview code

[Al-rawachy]

Hi all,

I have an array with 1 million elements, Iam doing multiple processing on this data which makes the code too slow(more than usual), Can you please give me any idea to overcome this issue? Thanks in advance

[JÞB]

You know what questions come next.  What is the datatype of the element, U8, EXT, Cluster of <Huge class, Big Class, string>?  What sort of processing are you doing? Large Data sets management starts here you are not the first to need to read that article

[Ben]

Yes, start with Jeff's suggestion.

If that did not help then I suggest taking a look at this tag cloud that contains links to many performance realted threds.

[Kyle97330]

A quick thing you can try is to open all SubVIs you have doing the processing, go to their properties on the "Execution" category, and change the priority of those VIs to "subroutine", assuming they qualify.  See the quote from the help file below:

The Subroutine priority level permits a VI to run as efficiently as possible. VIs that you set for Subroutine priority do not share execution time with other VIs.

When a VI runs at the Subroutine priority level, it effectively takes control of the thread in which it is running, and it runs in the same thread as its caller. No other VI can run in that thread until the subroutine VI finishes running, even if the other VI is at the Subroutine priority level. In single-threaded applications, no other VI runs. In execution systems, the thread running the subroutine does not handle other VIs, but the second thread of the execution system, along with other execution systems, can continue to run VIs.

In addition to not sharing time with other VIs, subroutine VI execution is streamlined so that front panel controls and indicators are not updated when the subroutine is called. A subroutine VI front panel reveals nothing about its execution.

A subroutine VI can call other subroutine VIs, but it cannot call a VI with any other priority. Use the Subroutine priority level in situations in which you want to minimize the overhead in a subVI that performs simple computations.

Also, because subroutines are not designed to interact with the execution queue, they cannot call any function that causes LabVIEW to take them off of the queue. That is, they cannot call any of the Wait, GPIB, VISA, or Dialog Box functions.

[Hatef.fouladi]

you have to give more information
the way your array is created ?
kind of array ?
your multiple processing type ?

[Al-rawachy]

hi All, 

Thanks for your kind response, the array has been created by fetching IQ data which's been sent from the refsg by generating power and frequency sweep for 10 step of 1M samples, the array as you know is just DBL (doublr precision. 

the problem that i have is that there is no synchronization between generator and receiver cause I have to chassis one for generatores and other one for receivers, thus, I am re arrange the data by do some searching for the elements in the mentioned array and get some information which can be served in the result. that's it. Thanks in advance

[altenbach]

---

@Al-rawachy wrote:

Thanks for your kind response, the array has been created by fetching IQ data which's been sent from the refsg by generating power and frequency sweep for 10 step of 1M samples, the array as you know is just DBL (doublr precision. 

the problem that i have is that there is no synchronization between generator and receiver cause I have to chassis one for generatores and other one for receivers, thus, I am re arrange the data by do some searching for the elements in the mentioned array and get some information which can be served in the result. that's it. Thanks in advance

---

Are we still talking about the same thing? Earlier you talked about processing a 1M array with multiple steps. Now you are talking about IQ data and synchronization between parallel processes.

Your description is very vague and not sufficient to provide any help.

Isn't IQ data typically complex. Maybe it would be easier to carry it around as complex data type instead of I and Q arrays.

You also haven't really told us how slow the code currently is and how fast it should be?

The most important perforrmance "trick" is inplaceness.This means operate on fixed size arrays and don't contantly grow and shrink them.

For large data structures it is also important to avoid extra data copies in memory. Don't use value property nodes or local variables to shuffle things around. Inline subVIs or at least keep their front panel closed. Avoid anything that forces their front panel to be in memory.

We really need to see a simplified version of your VI in order to provide more specific advice.

(use e.g. simulated data because we don't have your instrument, omit all the irrelevant things). 

[AliasAlreadyOnFile]

This may or may not be relevant, but if you're going to grow an array, be sure to append elements to the array, not prepend. If you have to prepend, reverse the array and append then reverse again. It's something like 100x faster because of the way memory is managed.

[Al-rawachy]

Sorry about my explanation if it was vague, I have attached the Vi(correct the window) that i've done to process the data of 1M samples. this Vi makes the program so slow when I want to change the values, for example, number of steps or input power etc.., but it executes normal without any delay. 

Regards

[altenbach]

• There are quite a few subVIs missing, so we cannot really run it.
• it seems overly expensive to get the I and Q from the complex input data, then convert it back to DBL a nanosecond later. That probably shold be done in a subVI since you never use the intermediary data.
• Your big VI is itself a subVI. How often does it get called? What is the point of "request deallocation"? Have you tried without it?
• None of your local variables are needed. eliminating them would also eliminate the sequence structure.
• There is a long sequence of "delete from array" and "insert into array" Are you sure this could not be simplified and done mostly in-place and in fewer steps?

---

@Al-rawachy wrote:

Sorry about my explanation if it was vague, I have attached the Vi(correct the window) that i've done to process the data of 1M samples. this Vi makes the program so slow when I want to change the values, for example, number of steps or input power etc.., but it executes normal without any delay. 

---

I assume you are changing these values in the calling program and that the attached subVI does not have the front panel open. Is this correct? Again, how often are you calling this? (over and over? whenever a control changes?).

You still have not told us your definition of "so slow". How slow is that? Do you have some numbers? Are you graphing 1M data in the calling VI? What else does the calling VI do? How long does it take for the subVI to complete?