LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange Performance Issue

Solved!
Go to solution

Hi,

I made a VI which counts the pulses from a quadrature encoder using the boolean crossing.vi and noticed very high CPU usage while the VI is running. A and B signals are received from the encoder which generates 0-5V levels using a cRIO with NI 9223 AI modules. I found that if I implement the logic behind boolean crossing.vi in my For loop, the VI execution speed increases by a factor of 60 and I could not explain why. It's expected to gain some speed if code from subVI is implemented directly in caller but that much? It seems that it makes a huge difference if I use two instances of the boolean crossing.vi or only one. Any thoughts?

I'm using LabVIEW 2018 SP1.

LucianM_2-1620417025797.pngLucianM_3-1620417053442.png

LucianM_4-1620417080174.png

 

 

 

Lucian
CLA
0 Kudos
Message 1 of 5
(1,378 Views)
Solution
Accepted by LucianM

I can't test the code at the moment, but I have seen similar effects so I am going to trust that you are seeing something real.  It seems that when you put two of those VIs together with no dataflow dependence between them that you are generating a thread switch during execution.  One way to test this theory is to place the two pt-by-pt functions in the first image inside consecutive frames of a flat sequence structure, or otherwise introduce a fake dataflow dependence between the two VIs.  See if you measure a significant improvement in performance.

Message 2 of 5
(1,330 Views)

@Darin.K wrote:

I can't test the code at the moment, but I have seen similar effects so I am going to trust that you are seeing something real.  It seems that when you put two of those VIs together with no dataflow dependence between them that you are generating a thread switch during execution.  One way to test this theory is to place the two pt-by-pt functions in the first image inside consecutive frames of a flat sequence structure, or otherwise introduce a fake dataflow dependence between the two VIs.  See if you measure a significant improvement in performance.


I just tried making a copy of the VI and setting it to inline. Oddly this did not make any significant performance increase.

 

Also on a side note, the numbers are all slower on my PC which is kind of surprising. It is a pretty beefy machine. I have 16 cores with a base speed of 2.1 GHz (2 sockets) giving me 32 logical processors along with with 32 GB of RAM.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 3 of 5
(1,317 Views)

I haven't solved it, but I found something else fun...

 

If you enable edit mode on the Boolean Crossing VI, and change it from normal priority to a higher priority, the execution time goes WAY up.  Like, it takes over 100 times longer on my setup (on the frame with the two copies).

 

However, if I set it to "Subroutine" priority, instead of taking 100 times longer it takes about 10 times less to run.

 

Not saying that changing the priority of a vi.lib file should be the way to go to fix it, but maybe it's a hint about what's going on?  A fight for resources, maybe?

Message 4 of 5
(1,305 Views)

@Kyle97330 wrote:

 

However, if I set it to "Subroutine" priority, instead of taking 100 times longer it takes about 10 times less to run.


 Subroutine priority forces the SubVI to run in the same thread as the caller, so this is further evidence that thread swapping is the performance bottleneck here.  In fact, this setting forces the two calls to run single-file as if you had placed a dataflow dependency between them.

Message 5 of 5
(1,295 Views)